openjdk build pages

Thu May 22 23:41:39 UTC 2014

Don't use GA, just always redefine the jdk7u40 tag to refer to the latest build of that update.
You can redefine the jdk7u40 tag every time you create the jdk7u40-bNNN tag.

So jdk7u40 becomes "the latest", and ultimately, the "final" one.

-kto

On May 21, 2014, at 7:08 PM, David Holmes wrote:

> On 22/05/2014 11:47 AM, Martin Buchholz wrote:
>> Another way to look at it is that "jdk7u40" is a tag that will gather
>> far more interest than the build-specific tags "jdk7u40-b62" currently
>> available, which are likely mostly of interest to Oracle release
>> engineering.
> 
> The problem with the build tags is that you have to know which build is the GA build beforehand - so a "GA" tag would be generally useful I think.
> 
> But that would not address the issue with non-public releases, like 7u55, as there is no GA build of that release in that forest. Even if you add a tag after all the corresponding changesets are added, that wont give you 7u55, it will give you 7u plus the 7u55 changes.
> 
> David
> ------
> 
>> 
>> On Wed, May 21, 2014 at 6:38 PM, Martin Buchholz <martinrb at google.com
>> <mailto:martinrb at google.com>> wrote:
>> 
>>    A slight tangent, but maybe y'all could expand the URLs that allow
>>    you to download an entire repo to make this particular way of
>>    grabbing bundles more convenient:
>> 
>>    1. In addition to the various labels like "jdk7u40-b62" that include
>>    a build number, when jdk7u40 is finally released, simply add a tag
>>    "jdk7u40" that is the true final released jdk7u40.  It would point
>>    to the same revision as the last build, presumably jdk7u40-b62".
>>      This allows you to download via URL, e.g.
>> 
>>    http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/archive/jdk7u40.zip
>>    <https://www.google.com/url?q=http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/archive/jdk8u5-b13.zip&usg=AFQjCNEkVB2epNK4B2YZSjcgmwvrvCqF0g>
>> 
>>    2.  (some hg hacking required) Expand the per-repo URLs to download
>>    all the repos with one URL, e.g.
>> 
>>    http://hg.openjdk.java.net/jdk7u/jdk7u/whole-tree/archive/jdk7u40.zip <https://www.google.com/url?q=http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/archive/jdk8u5-b13.zip&usg=AFQjCNEkVB2epNK4B2YZSjcgmwvrvCqF0g>
>> 
>> 
>>    On Wed, May 21, 2014 at 4:44 PM, Omair Majid <omajid at redhat.com
>>    <mailto:omajid at redhat.com>> wrote:
>> 
>>        * dalibor topic <dalibor.topic at oracle.com
>>        <mailto:dalibor.topic at oracle.com>> [2014-05-21 05:15]:
>>         > Actually, I think that for 7u60 (and 7u80) we need to move in
>>        the other
>>         > direction, and not publish separate source bundles from the
>>        source code
>>         > that's already in the Project's Mercurial repositories.
>> 
>>        I encourage you to think again. The source code system used by
>>        OpenJDK
>>        (hg trees) is not straight-forward to work with for packagers,
>>        and needs
>>        non-standard tools, like the trees extension, to fetch complete and
>>        consistent things.
>> 
>>        Source bundles are really easy to work with as a packager. You
>>        know you
>>        got something consistent that works and don't have to mess
>>        around with
>>        source code control systems checking out various repositories
>>        and tags
>>        to find the 'right' source.
>> 
>>         > Beside being potentially error prone,
>> 
>>        I am not sure I understand. Surely you can write a script that
>>        grabs the
>>        right tags from the right forests to create a tarball. I could
>>        do it, if
>>        I knew exactly which forests and tags contain the right stuff
>>        (and could
>>        upload it somewhere on openjdk.java.net
>>        <http://openjdk.java.net>). In fact, I have something
>>        generic already written [1]. Feel free to use it.
>> 
>>         > and update releases that we can't work on as part of OpenJDK
>>        (like
>>         > 7u55),
>> 
>>        I am not sure I follow. If you can commit the source to the
>>        repository
>>        and tag it, why can't you create a source bundle for those tags?
>> 
>>         > The added complexity provides little benefit, and the
>>        simplest way to remove
>>         > the complexity is to remove the issue causing it, and educate
>>        users to use
>>         > the source ... directly from the respective source repository.
>> 
>>        I respectfully disagree with your solution. If not providing source
>>        bundles causes confusion, wouldn't the right fix be to provide
>>        source
>>        bundles?
>> 
>>        As for benefit, just today I saw people asking on #openjdk about
>>        where
>>        to get source bundles. And they complained that using source
>>        control to
>>        get a release bundles is too hard (and shouldn't be necessary).
>> 
>>        Also, if you think users have problems distinguishing 7u60 from
>>        7u55,
>>        can you imagine the problems they will have trying to find the
>>        real/final tag for 7u55 in the repos? And how some tags do not
>>        exist in
>>        some repos at some points in time? [2].
>> 
>>        Thanks,
>>        Omair
>> 
>>        [1]
>>        http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh
>>        [2]
>>        http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html
>>        --
>>        PGP Key: 66484681 (http://pgp.mit.edu/)
>>        Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
>> 
>> 
>> 