Project Proposal: JDK 7 Update

[mark.reinhold at oracle.com]

2011/6/16 4:20 -0700, mark at klomp.org:
> On Thu, 2011-06-16 at 12:18 +0200, Dalibor Topic wrote:
>> Sure. The reason for new repos is to ensure that the materials associated 
>> with the JDK 7 Release Project remain available long-term rather than get 
>> buried under JDK 7 Update materials.
> 
> What do you mean by buried? You just have to tag the repositories with
> for each release/update to get exactly at the source at that time. Look
> at how openjdk6 handles this. There is just one jdk6 forest with each
> update release tagged. That is a much smoother model to follow IMHO.
> Otherwise one quickly cannot find the forests through the trees :)

There are other materials in the JDK 7 Project besides code.  The various
web pages describing schedule, features, milestones, etc., are likely to
be of historical interest over the long term.  If we use the existing JDK
7 Project for updates then that material would become harder to find, if
not eventually lost altogether.  The relevant URLs would almost certainly
change.

To put it another way, these are logically distinct Projects, with
distinct participants, goals, and processes.  Shoe-horning them into
a single Project just risks confusing people.

Finally, using the JDK 7 Project for updates would be inconsistent with
the proposed Bylaws, which define a "JDK Release Project" as being for
"new releases of Java SE Platform implementations".  Update releases do
not fit that definition.

Aside from the issue of which Project to use, there will be multiple
forests as Dalibor explains in his Q&A [1]: A mainline forest that's
always open for incoming changesets, so that developers have somewhere
to put their changes, and a forest for each actual update release, so
that each release can be stabilized independently of the mainline.

This is just the natural way to use a distributed VCS for parallel
streams of development.  Yes, Mercurial has branches, but they're
generally not recommended by experts [2] and from what I've seen they
haven't worked out all that well in practice.  (If I recall correctly
they were used briefly in IcedTea and then abandoned.)

I honestly don't understand the aversion, expressed by some, to the
creation of new forests.  Disk space is cheap.  What's the problem?

- Mark


[1] http://cr.openjdk.java.net/~robilad/jdk7u/7UpdateQAndA.txt
[2] http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html#id386031