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

[Dr Andrew John Hughes]

On 22:11 Mon 19 Dec     , Deepak Bhole wrote:
> * 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?

Third time of reading this, my mail might stay up long enough to reply...

I think having a mismatch between the IcedTea and IcedTea forest versions
is even more confusing.

As I said in my previous response, I don't see the value in this.  It is
not the IcedTea version that has caused issues in the past, to my knowledge,
but the OpenJDK6 build drop version.

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

I don't understand your point here.  We already do this.  With the next security
update, I would expect a 2.0.1 and 2.1.1 if 2.1 has happened by then.

> Cheers,
> Deepak

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20111221/f0c4e3af/attachment.bin