Hi Jesse,
Jesse Keating wrote:
On Wednesday 12 July 2006 16:58, Fernando Nasser wrote:
And for what? What are the technical advantages that will be obtained
with this change? If we knew what effect wants to be obtained we could
perhaps think together in a better way to solve it.
Right now it is difficult to respin a release on say FC5 w/out running into
having it be versioned HIGHER than that in FC6 or in devel. If we're going
to adopt the jpackage naming scheme into our guidelines there needs to be
some thought put around this.
Of course.
We recently approved the ability to add an int after the dist tag for this
purpose, so that the release could be:
<int>%{?dist}.<int> or once translated:
3.fc6.1
Sounds good to me.
This keeps it lower than say 3.fc7 but allows for it to be respun w/out having
to bump the fc7 version.
Nice idea. So far so good.
How can this fit into the jpp naming scheme as it stands? Currently there is
just 'fc', no indication which Fedora release, and there are no numbers after
it. This should be addressed.
I wish so much this would be the only problem that people would be
seeing. Because any, absolutely any, suffix scheme to whatever the JPP
release is would work fine for JPackage as well.
MMMMMM-N.N.N-NNNNjpp<suffix>
where suffix could perfectly be <int>%{?dist}.<int>
We need a separator though.
I think it could be proposed a second use for underscores in addition to
package with underscores on well known upstream names.
Underscores could also be used to clearly separate releases when the
packaging is imported from upstream.
Mind, today it is just JPackage and the Java packages, but who can tell
that in a few years there won't be this huge meta system with it's all
multi-distro package community that we (we == Fedora in this case) would
like to import as effortlessly as possible? The character release
separator '_' would come into play again.
In any case, any other separator would do, even a '.' if special-cased
when following a 'jpp' (or any other future upstream packaging community).
So, all that would remain would be to make the upstream JPackage release
practices a little bit more palatable for your tastes (note that I say
taste, I don't think tere are technical reasons like the one you presented).
I really elieve JPP folks would be agreeable on following the sae
standards as Fedora for instance for cvs date tags. I forgot now, what
is it 0.cvsYYYYMMDD.... ?
The '0.' prefix for pre-releases is very important, as it is intended to
lose for the final '1'.
And the pre-release tags? We have been obeying strictly what the
upstream software produced is using. This means that if they say it is
'rc2' then JPP has 0.rc2.... but if they say it is 'M4', it becomes
0.M4.... Strictly what the developers called it and the software web
site refers to it as (normally it is also in the sorce tar ball name).
Here comes the 1st problem: uppercase characters.
We have another situation that will need discussion: several upstream
packages are now using snapshots of dependencies before the official
release that are being identified only by a CVS Tag. Not date, Tag!
This means underscores!!!
What I really would think should be fair in the case of upstream
packaging communities would be to apply the Fedora standards only after
the separator, i.e., to the Fedora added suffix.
In any case, I believe that reasonable suggestions to improve the
upstream release numbering will be welcome, they must be presented at
that project list though:
jpackage-discuss@xxxxxxxx
Also notice that these changes will not come overnight, as noticed in
this thread before. There are releases there too, and packages for the
next one on August 15 are basically ready. They are many, and it took
months to get to this point.
Also, there are upgrade considerations wit regards to previous JPP
releases and many other things that would need to be exhaustively
tested. It is a project that exists since before Fedora was even born:
it had releases for RHL 8 or before if I am not mistaken.
Note that is not only Fedora that imports the RPMs from JPackages.
Other distributions and Java SDK providers also use it and may want to
have a say as well.
In summary Jesse, we have no attachment to the _Nfc bit in particular.
Any suffix will do, whatever works better for Fedora. Changes in the
upstream release string is what causes interoperability problems.
Thanks a lot for posting a specific technical issue. It works so much
better that way.
Best regards,
Fernando
