Coherent release process

[Quanah Gibson-Mount]

Hi,

I was wondering if/when the OpenJDK project may develop a more coherent 
release plan?  Right now, there seems to be no consistent strategy, which 
makes it very difficult for downstream consumers of OpenJDK to be able to 
reliably build out new OpenJDK releases.  While I appreciate that the 
process has become easier with OpenJDK 8 vs the prior OpenJDK versions, 
right now the build process for new releases, particularly critical 
security updates, seems quite the mess.

For example:

To build OpenJDK 1.8u66, you have to use the jdk8u (JDK 8 Updates Master) 
branch (doesn't make sense)
To build OpenJDK 1.8u60, you use the jdk8u60 release branch (makes sense)
To build OpenJDK 1.8u51, you use the jdk8u60-dev branch (doesn't make sense)

The lack of consistency among branches for different releases makes it 
extremely hard to create a well defined build process for OpenJDK.

In addition the fact that the bug system is locked down makes it extremely 
hard to report issues back upstream, such as the fact that the hgforest.sh 
script doesn't correctly honor command arguments, meaning that it has to be 
patched to get a consistent build of the downstream modules that get 
checked out.  The following patch fixes this rather significant problem.

<http://fpaste.org/289480/44729880/>

As we rely heavily on being able to provide up to date, consistent, secure 
OpenJDK builds to our customers, having the process to build new releases 
be reliable is of significant importance.  I imagine that is the case for 
many others as well.

Thanks for your time and consideration,
Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration