On 19/04/12 17:31, Juan Hernandez wrote: > 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 >>>>>>>>>> [email protected] >>>>>>>>>> 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 Great, 10x!
-- /d "All computers wait at the same speed." _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
