[Engine-devel] Jar versions in ovirt-engine

[Juan Hernandez]

On 04/19/2012 12:00 PM, Doron Fediuck wrote:
> On 18/04/12 14:04, Juan Hernandez wrote:
>> On 04/18/2012 09:51 AM, Ofer Schreiber wrote:
>>> Ever wondered why the version of oVirt's first release is 3.0.0_0001?
>>> The answer is simple - We use ovirt-engine jar's version as our "main" release version.
>>>
>>> Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.
>>>
>>> What can we do about it? We have couple of options:
>>> 1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
>>> 2. Remove "_" from engine jars
>>> 3. Do nothing.
>>>
>>> I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.
>>>
>>> ---
>>> Ofer Schreiber
>>> oVirt Release Manager
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>> From my point of view using the 0001 suffix in the names of the jar
>> files is not a big problem, but I agree that using it in the release
>> number is ugly, and it produces issues/discussions during packaging. I
>> vote for option #1: use 3.1.0 for the next main version.
>>
> 
> The original versioning scheme was due to a bug in maven2.
> 
> Juan, I've read some of the Java packaging concepts, but didn't see
> (or missed) thoughts about modular versioning (ie- artifacts).
> 
> Here are the things to consider here;
> 
> - Current RPM's are using the version declared in the POM files.
> Should this concept remain?
> * I think it should remain, as other packaging systems should
> be able to use it as well and end-up is the similar project version.

I can talk from the Fedora point of view only, as that is what I know a bit.

In Fedora there can be only one version of a given jar file installed in
the system, so there is no point in adding a version number to the name
of that jar file: the version number is already in the package
containing that jar file. In fact if the build generates jar files with
version numbers in the name the RPM should remove those jar files. That
is why I say that having any kind of numbers in the names of the jars is
not important: we have to remove them anyway.

Packaging guidelines (see [1]) recommend to avoid version numbers in the
jar files, and I think that makes sense.

On the other hand adding that _0001 suffix to the project itself
complicates (just a bit) the packaging. It has to be discussed where
that "postrelease" number has to go: in the version tag of the package,
in the release tag? You can see an example of that discussion in the
review bug of the ovirt-engine package (see [2]).

> - Do we want to expose oVirt engine artifacts in a Maven repo
> for others to consume?
> * If we do, we'll need to make sure we have a scheme that works both for
> Maven and for packaging (RPM) comparisons.

I think that we don't need to make the artifacts available for others
now. Is anyone consuming those artifacts? However I agree that is good
to have numbering that works for Maven and RPM.

> One last thing...
> I know most of the packaging work now is RPM based. Still, I'm
> asking you to leave enough room for non-RPM distro's to join in.

I am a bit (well, maybe a byte) RPM biased, mainly because that is what
I know, but I don't want to complicate packaging with other mechanisms.
Please let me know if I do :-) .

[1] - https://fedoraproject.org/wiki/Packaging:Java#Filenames
[2] - https://bugzilla.redhat.com/show_bug.cgi?id=807017#c13