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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/arch

From my point of view using the 0001 suffix in the names of the jar

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(a)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.

- 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.

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.

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(a)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?

On 04/19/2012 03:22 PM, Doron Fediuck wrote: > On 19/04/12 13:26, Juan Hernandez wrote: >> 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(a)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. >> > This would be the easy solution. Again talking only about Fedora: Having just one version of every jar is not simple at all, in fact it requires a lot of work to make sure that the selected versions work properly together.

> What happens when you have more than a single Java app, and both > using different versions of the same jar file? This means that one > of the app's will need to bring it along and use it locally, rather > than system-level usage. What happens is that both applications have to be patched so that they work correctly with the same version of that jar file. If possible the patches are pushed upstream, if not they applied as part of the package. Embedding another version of that jar file in one of the applications is not allowed, in fact that is something that packagers have to undo quite often.

> I'm guessing if we assume such a constraint the solution will be > to force all app's to use latest jar version, which isn't trivial. I agree completely, it is not trivial at all, that is where packagers expend most of their time. > So some distro's will allow of concept of slotted installation. > This means I currently /have/ 2 working versions of postgres in > my laptop (using Gentoo)- > > equery l postgresql-server > * Searching for postgresql-server ... > [IP-] [ ] dev-db/postgresql-server-8.4.11:8.4 > [IP-] [ ] dev-db/postgresql-server-9.1.3:9.1 > > The same works on my laptop for Maven, Java, Python and many others. > If you think about it, Fedora supports slotted installation for > kernels, and then added alternatives to do that with other packages > as well (mta, Java..). So there's a need and a way to handle several > versions of the same library (regardless of the language), and > we should be careful when taking such assumptions. At least try > to be as flexible as possible, to allow others to join in. In Fedora that is allowed only for major versions: java-1.7.0 and java-1.6.0, maven 2 and maven 3, so on, but not usually for minor versions (there are exceptions).

> So learning from Fedora I'd say- let the RPM install in a versioned > folder (ie- /usr/lib/jvm/jre-1.5.0-gcj/..), and leave the jar > files without versions for now. In the future we may need to change it > as some disrto's may use sym links to indicate the latest jar. > In such a case the RPM will stripdown the version from the artifact. What we are currently doing with the Fedora ovirt-engine package is that jar files are installed to /usr/share/java/ovirt-engine, with names like bll.jar, common.jar, compat.jar, etc. The RPM takes care of stripping the version numbers generated by the upstream build. This doesn't preclude other distros from doing it in a different way, using version numbers or symlinks.

On 04/19/2012 04:10 PM, Doron Fediuck wrote: > On 19/04/12 16:53, Juan Hernandez wrote: >> On 04/19/2012 03:22 PM, Doron Fediuck wrote: >>> On 19/04/12 13:26, Juan Hernandez wrote: >>>> 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(a)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. >>>> >>> This would be the easy solution. >> >> Again talking only about Fedora: >> >> Having just one version of every jar is not simple at all, in fact it >> requires a lot of work to make sure that the selected versions work >> properly together. >> > See below, we actually share the same view... > >>> What happens when you have more than a single Java app, and both >>> using different versions of the same jar file? This means that one >>> of the app's will need to bring it along and use it locally, rather >>> than system-level usage. >> >> What happens is that both applications have to be patched so that they >> work correctly with the same version of that jar file. If possible the >> patches are pushed upstream, if not they applied as part of the package. >> Embedding another version of that jar file in one of the applications is >> not allowed, in fact that is something that packagers have to undo quite >> often. >> > See below... converging into the latest jar is what I figured that > will happen. Still, as I see it such constraints are not really needed. >>> I'm guessing if we assume such a constraint the solution will be >>> to force all app's to use latest jar version, which isn't trivial. >> >> I agree completely, it is not trivial at all, that is where packagers >> expend most of their time. >> >>> So some distro's will allow of concept of slotted installation. >>> This means I currently /have/ 2 working versions of postgres in >>> my laptop (using Gentoo)- >>> >>> equery l postgresql-server >>> * Searching for postgresql-server ... >>> [IP-] [ ] dev-db/postgresql-server-8.4.11:8.4 >>> [IP-] [ ] dev-db/postgresql-server-9.1.3:9.1 >>> >>> The same works on my laptop for Maven, Java, Python and many others. >>> If you think about it, Fedora supports slotted installation for >>> kernels, and then added alternatives to do that with other packages >>> as well (mta, Java..). So there's a need and a way to handle several >>> versions of the same library (regardless of the language), and >>> we should be careful when taking such assumptions. At least try >>> to be as flexible as possible, to allow others to join in. >> >> In Fedora that is allowed only for major versions: java-1.7.0 and >> java-1.6.0, maven 2 and maven 3, so on, but not usually for minor >> versions (there are exceptions). >> > It's a good start. > >>> So learning from Fedora I'd say- let the RPM install in a versioned >>> folder (ie- /usr/lib/jvm/jre-1.5.0-gcj/..), and leave the jar >>> files without versions for now. In the future we may need to change it >>> as some disrto's may use sym links to indicate the latest jar. >>> In such a case the RPM will stripdown the version from the artifact. >> >> What we are currently doing with the Fedora ovirt-engine package is that >> jar files are installed to /usr/share/java/ovirt-engine, with names like >> bll.jar, common.jar, compat.jar, etc. The RPM takes care of stripping >> the version numbers generated by the upstream build. This doesn't >> preclude other distros from doing it in a different way, using version >> numbers or symlinks. >> > Why not /usr/share/java/ovirt-engine-3/ ? I do not see someone using > engine3 and engine4 on the same machine, but he may need to have > engine-config v3 to handle previous instance and engine-config v4 > to handle current instance, so we could have a good infra if we > keep the major version. The only thing I have against ovirt-engine-3 is that the packaging guidelines recommend to use /usr/share/java/%{name}, where %{name} is the name of the package, and the package has already been approved with the name ovirt-engine. Next major version (not 3.1, that is a minor version) can perfectly be named ovirt-engine4 or ovirt4-engine.

On 04/19/2012 04:21 PM, Doron Fediuck wrote: > On 19/04/12 17:17, Juan Hernandez wrote: >> On 04/19/2012 04:10 PM, Doron Fediuck wrote: >>> On 19/04/12 16:53, Juan Hernandez wrote: >>>> On 04/19/2012 03:22 PM, Doron Fediuck wrote: >>>>> On 19/04/12 13:26, Juan Hernandez wrote: >>>>>> 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(a)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. >>>>>> >>>>> This would be the easy solution. >>>> >>>> Again talking only about Fedora: >>>> >>>> Having just one version of every jar is not simple at all, in fact it >>>> requires a lot of work to make sure that the selected versions work >>>> properly together. >>>> >>> See below, we actually share the same view... >>> >>>>> What happens when you have more than a single Java app, and both >>>>> using different versions of the same jar file? This means that one >>>>> of the app's will need to bring it along and use it locally, rather >>>>> than system-level usage. >>>> >>>> What happens is that both applications have to be patched so that they >>>> work correctly with the same version of that jar file. If possible the >>>> patches are pushed upstream, if not they applied as part of the package. >>>> Embedding another version of that jar file in one of the applications is >>>> not allowed, in fact that is something that packagers have to undo quite >>>> often. >>>> >>> See below... converging into the latest jar is what I figured that >>> will happen. Still, as I see it such constraints are not really needed. >>>>> I'm guessing if we assume such a constraint the solution will be >>>>> to force all app's to use latest jar version, which isn't trivial. >>>> >>>> I agree completely, it is not trivial at all, that is where packagers >>>> expend most of their time. >>>> >>>>> So some distro's will allow of concept of slotted installation. >>>>> This means I currently /have/ 2 working versions of postgres in >>>>> my laptop (using Gentoo)- >>>>> >>>>> equery l postgresql-server >>>>> * Searching for postgresql-server ... >>>>> [IP-] [ ] dev-db/postgresql-server-8.4.11:8.4 >>>>> [IP-] [ ] dev-db/postgresql-server-9.1.3:9.1 >>>>> >>>>> The same works on my laptop for Maven, Java, Python and many others. >>>>> If you think about it, Fedora supports slotted installation for >>>>> kernels, and then added alternatives to do that with other packages >>>>> as well (mta, Java..). So there's a need and a way to handle several >>>>> versions of the same library (regardless of the language), and >>>>> we should be careful when taking such assumptions. At least try >>>>> to be as flexible as possible, to allow others to join in. >>>> >>>> In Fedora that is allowed only for major versions: java-1.7.0 and >>>> java-1.6.0, maven 2 and maven 3, so on, but not usually for minor >>>> versions (there are exceptions). >>>> >>> It's a good start. >>> >>>>> So learning from Fedora I'd say- let the RPM install in a versioned >>>>> folder (ie- /usr/lib/jvm/jre-1.5.0-gcj/..), and leave the jar >>>>> files without versions for now. In the future we may need to change it >>>>> as some disrto's may use sym links to indicate the latest jar. >>>>> In such a case the RPM will stripdown the version from the artifact. >>>> >>>> What we are currently doing with the Fedora ovirt-engine package is that >>>> jar files are installed to /usr/share/java/ovirt-engine, with names like >>>> bll.jar, common.jar, compat.jar, etc. The RPM takes care of stripping >>>> the version numbers generated by the upstream build. This doesn't >>>> preclude other distros from doing it in a different way, using version >>>> numbers or symlinks. >>>> >>> Why not /usr/share/java/ovirt-engine-3/ ? I do not see someone using >>> engine3 and engine4 on the same machine, but he may need to have >>> engine-config v3 to handle previous instance and engine-config v4 >>> to handle current instance, so we could have a good infra if we >>> keep the major version. >> >> The only thing I have against ovirt-engine-3 is that the packaging >> guidelines recommend to use /usr/share/java/%{name}, where %{name} is >> the name of the package, and the package has already been approved with >> the name ovirt-engine. Next major version (not 3.1, that is a minor >> version) can perfectly be named ovirt-engine4 or ovirt4-engine. > > Maybe open a bz for it so we'll remember? > Make sure to add this thread so we'll know what happened.... There you go: https://bugzilla.redhat.com/814295