icedtea7 releases (was Re: RFC: backport S7104625 to icedtea7 forest)

[Deepak Bhole]

* Dr Andrew John Hughes <ahughes at redhat.com> [2011-12-13 19:26]:
> On 17:10 Tue 13 Dec     , Omair Majid wrote:
> > On 12/12/2011 06:11 PM, Dr Andrew John Hughes wrote:
> > >> If you need this fix earlier, I can add this to icedtea7 as well. Though
> > >> I would rather avoid the extra work and just wait until the next sync :)
> > >>
> > >
> > > I think this is something we need to discuss.  I've not had much luck finding
> > > out the schedule for these updates from Oracle.  From
> > >
> > > http://openjdk.java.net/projects/jdk7/builds/
> > >
> > > it seems that u2 is supposed to be released tomorrow, but I see little discussion
> > > about this on the jdk7u mailing list.  There are no dates on that calendar for
> > > future releases.
> > >
> > > We should look at pulling u2 into IcedTea7 and doing a 2.1 release.  I'll post a
> > > list of changesets to see what this equates to.
> > >
> > > We also need to discuss how we are going to handle such updates generally.
> > > As we don't even know when u4 is going to appear, it may be judicious to backport
> > > this particular changeset ourselves to IcedTea7.
> > >
> > 
> > I would like to add my thoughts to this discussion.
> > 
> > First, I think it would be beneficial to keep version numbers as close 
> > to openjdk/proprietary jdk as possible. It was quite strange in the 
> > openjdk6 time-frame where the openjdk (6bXX) releases were not related 
> > to proprietary jdk6 (6uYY) at all. I recall a number of users saying 
> > that because YY was greater than XX, openjdk was lagging behind the 
> > proprietary jdk.
> 
> Well yes, that's true and Oracle acknowledge it too.  But this
> couldn't be helped; due to the genealogy of OpenJDK6 the two are
> completely unrelated and incomparable, coming from completely
> different code repositories.  Thankfully, this period is mostly behind
> us now.
> 
>  I imagine it will be hard for users to figure out that 
> > icedtea2.1 is approximately openjdk7u2, and not openjdk7u1. Perhaps we 
> > can even utilize this to our advantage and keep odd minor numbers (2.1, 
> > 2.3, 2.5 and so on) reserved for our own releases which may contain 
> > important non-openjdk stuff (I am thinking of things like ports, 
> > architecture support, a number of important bug fixes. and so on).
> > 
> 
> I think that would be difficult to make work because it puts hard constraints
> on what we can do; it would be more confusing if we skip version numbers
> because there are e.g. no ARM support changes to make a 2.3 release, so
> we end up going 2.0, 2.2, 2.4, 2.5 or something.

Perhaps there should be a distinction between icedtea and the forest
versions then.

The idea of the forest is to be as close to upstream openjdk as possible
with minimal patches. In light of this, it makes sense to make the
versions there match i.e. icedtea7-forest-2.2, icedtea7-forest-2.4, etc.

How about that?

> We also have a tradition of following the more usual FOSS pattern of applying
> security updates to supported releases rather than doing a whole new release
> for a security update as Oracle does for Java and Mozilla do for Firefox.
> I believe distros find this better, but speak up if this isn't the case.
>

We can always do a micro bump to forest version for security. e.g.  2.0
+ security = 2.0.1 ... nothing in FSOSS tradition requires a minor
version bump.

Cheers,
Deepak