new convention for hsx project repository names

[Daniel D. Daugherty]

I like it! Details about how this will affect 'version' info
would be good (to echo David H)... I suspect we'll go back
to reporting the same version string for both JDK and VM:

$ /java/re/jdk/1.6.0_03/promoted/latest/binaries/solaris-i586/bin/java 
-version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)

and here's the first release where the version numbers diverged:

$ /java/re/jdk/1.6.0_04/promoted/latest/binaries/solaris-i586/bin/java 
-version
java version "1.6.0_04"
Java(TM) SE Runtime Environment (build 1.6.0_04-b12)
Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)

HSX-10... now at HSX-25... it's been a long road...

Dan


On 8/29/13 10:09 PM, John Coomes wrote:
> The hsx Project has maintained a version number for HotSpot that is
> distinct from the JDK version--for example HotSpot version hs24 is
> being delivered into jdk7u40, and hs25 into jdk8.  (For interested
> readers, some background info about separate versions is included at
> the end of this message.)
>
> The separate version has also been reflected in repository paths, e.g.:
>
> 	http://hg.openjdk.java.net/hsx/hsx24
> 	http://hg.openjdk.java.net/hsx/hsx23
> 	http://hg.openjdk.java.net/hsx/hsx23.2
> 	http://hg.openjdk.java.net/hsx/hsx23.4
> 	...
>
> One often-mentioned problem with this naming scheme is that the
> correspondence between an hsx repository and the JDK release into which
> it will be delivered is not obvious.  So we are planning on changing the
> repository naming convention going forward.
>
> More precisely, the new repository for HotSpot (and HotSpot-related)
> changes targeting jdk7u60 and later 7 updates would be:
>
> 	http://hg.openjdk.java.net/hsx/jdk7u
>
> (The old convention would have used the name http://.../hsx/hsx24.<N>)
> This new repo will correspond to the jdk7u on-going development repo,
> i.e., http://hg.openjdk.java.net/jdk7u/jdk7u.
>
> Extending this a little into the future, once jdk7u60 reaches a point
> where a separate stabilization repo is needed, we will create
> http://hg.openjdk.java.net/hsx/jdk7u60.  At that time the hsx/jdk7u
> repo would change to target the following jdk7u update release (if
> there is one).
>
> Similar conventions would apply to repositories for jdk8 updates once
> we have a need for them.
>
> Existing hsx repos should continue to be used; in particular, we will
> continue to use the on-going development repos for the forseeable
> future:
>
> 	http://hg.openjdk.java.net/hsx/hotspot-main
> 	http://hg.openjdk.java.net/hsx/hotspot-comp
> 	http://hg.openjdk.java.net/hsx/hotspot-emb
> 	http://hg.openjdk.java.net/hsx/hotspot-gc
> 	http://hg.openjdk.java.net/hsx/hotspot-rt
>
> These are currently targeting jdk8, and will switch to jdk9 in the near
> future.  At that point a new jdk8 stabilization repo would be created:
>
> 	http://hg.openjdk.java.net/hsx/jdk8
>
> to be used instead of the existing hsx/hsx25 repo (hsx/hsx25 is
> currently used only by the hotspot gatekeeper, Alejandro Murillo).
>
> Despite the length of this message, I think the naming change is
> straightforward and will (slightly) simplify HotSpot development.
> Since there are already HotSpot changes pending for jdk7u60, I want to
> create the new repo within the next few days.  If you have questions
> or feedback, please follow-up on the list.
>
> Background on the separate HotSpot version number:
>
> Because the same HotSpot source has been delivered simultaneously into
> multiple JDK releases (e.g., builds of hs23 were delivered into jdk8 and
> into jdk7u4, builds of hs22 were delivered into early jdk8 builds and
> into jdk7u2, and so on), a separate HotSpot version facilitated tracking
> the sources as they propagated to different releases.  But at the same
> time, it also imposed the overhead of having to map from a HotSpot
> version to a JDK version and back again.  This is not always simple,
> particularly for those that do not work with HotSpot on a day-to-day
> basis.
>
> More recent hsx versions (hs24 and hs25), have really targeted only a
> single JDK release (although a few builds of hs24 did go into both jdk8
> and into jdk7u<N>).  We expect this trend to continue, and thus the
> overhead of mapping from a HotSpot version to a JDK version is
> unnecessary.
>
> -John
>