Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #30761 > unrolled thread

JDK 1.7.0_75 and 1..8.0_31 are out

Back to article view | Back to comp.lang.java.programmer

Contents

  JDK 1.7.0_75 and 1..8.0_31 are out Roedy Green <see_website@mindprod.com.invalid> - 2015-01-20 17:10 -0800
    Re: JDK 1.7.0_75 and 1..8.0_31 are out Roedy Green <see_website@mindprod.com.invalid> - 2015-01-20 17:16 -0800
      Re: JDK 1.7.0_75 and 1..8.0_31 are out Roedy Green <see_website@mindprod.com.invalid> - 2015-01-20 17:24 -0800
        Re: JDK 1.7.0_75 and 1..8.0_31 are out Arne Vajhøj <arne@vajhoej.dk> - 2015-01-21 21:13 -0500
          Re: JDK 1.7.0_75 and 1..8.0_31 are out Roedy Green <see_website@mindprod.com.invalid> - 2015-01-21 19:53 -0800
            Re: JDK 1.7.0_75 and 1..8.0_31 are out Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-01-22 11:36 -0600
              Re: JDK 1.7.0_75 and 1..8.0_31 are out Martin Gregorie <martin@address-in-sig.invalid> - 2015-01-22 21:23 +0000
              Re: JDK 1.7.0_75 and 1..8.0_31 are out Roedy Green <see_website@mindprod.com.invalid> - 2015-01-26 21:23 -0800
                Re: JDK 1.7.0_75 and 1..8.0_31 are out Martin Gregorie <martin@address-in-sig.invalid> - 2015-01-27 11:00 +0000
            Re: JDK 1.7.0_75 and 1..8.0_31 are out Arne Vajhøj <arne@vajhoej.dk> - 2015-01-24 21:27 -0500
              Re: JDK 1.7.0_75 and 1..8.0_31 are out Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-01-24 22:07 -0500
                Re: JDK 1.7.0_75 and 1..8.0_31 are out Arne Vajhøj <arne@vajhoej.dk> - 2015-01-24 22:21 -0500
                Re: JDK 1.7.0_75 and 1..8.0_31 are out Roedy Green <see_website@mindprod.com.invalid> - 2015-01-26 21:29 -0800
                  Re: JDK 1.7.0_75 and 1..8.0_31 are out Joerg Meier <joergmmeier@arcor.de> - 2015-01-27 08:58 +0100
                  Re: JDK 1.7.0_75 and 1..8.0_31 are out Arne Vajhøj <arne@vajhoej.dk> - 2015-02-01 09:43 -0500
              Re: JDK 1.7.0_75 and 1..8.0_31 are out Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2015-01-25 11:39 +0200
                Re: JDK 1.7.0_75 and 1..8.0_31 are out Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2015-01-25 20:56 +0200
              Re: JDK 1.7.0_75 and 1..8.0_31 are out Roedy Green <see_website@mindprod.com.invalid> - 2015-01-26 21:25 -0800
                Re: JDK 1.7.0_75 and 1..8.0_31 are out Arne Vajhøj <arne@vajhoej.dk> - 2015-02-01 09:35 -0500
      Re: JDK 1.7.0_75 and 1..8.0_31 are out Arne Vajhøj <arne@vajhoej.dk> - 2015-01-21 21:16 -0500
      Re: JDK 1.7.0_75 and 1..8.0_31 are out Arne Vajhøj <arne@vajhoej.dk> - 2015-01-21 21:22 -0500

Page 1 of 2  [1] 2  Next page →

#30761 — JDK 1.7.0_75 and 1..8.0_31 are out

JDK 1.7.0_75 and JDK 1.8.0_31 are out

1.7.0_76 in April will be the end of JDK  1.7. Autoupdate will flip
1.7 to 1.8.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
To solve an interesting problem, start by finding a problem
that is interesting to you.
~ Eric S. Raymond (born: 1957-12-04 age: 57)

[toc] | [next] | [standalone]

#30762

On Tue, 20 Jan 2015 17:10:23 -0800, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

>JDK 1.7.0_75 and JDK 1.8.0_31 are out
>
>1.7.0_76 in April will be the end of JDK  1.7. Autoupdate will flip
>1.7 to 1.8.

There is some confusion about 1.7.0_76.
The executable is called 1.7.0_75
The release notes for the current version are 1.7.0_76.

There was once a time when versions were simple sequential numbers.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
To solve an interesting problem, start by finding a problem
that is interesting to you.
~ Eric S. Raymond (born: 1957-12-04 age: 57)

[toc] | [prev] | [next] | [standalone]

#30763

On Tue, 20 Jan 2015 17:16:14 -0800, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

>There is some confusion about 1.7.0_76.

Companies like Oracle should be very conservative about changing their
naming conventions. Those conventions are burned into all manner of
build scripts, documentation, source code and schemes for
automatically incrementing the universe on a version change created my
Oracle's customers and users.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
To solve an interesting problem, start by finding a problem
that is interesting to you.
~ Eric S. Raymond (born: 1957-12-04 age: 57)

[toc] | [prev] | [next] | [standalone]

#30774

On 1/20/2015 8:24 PM, Roedy Green wrote:
> On Tue, 20 Jan 2015 17:16:14 -0800, Roedy Green
> <see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
> someone who said :
>
>> There is some confusion about 1.7.0_76.
>
> Companies like Oracle should be very conservative about changing their
> naming conventions. Those conventions are burned into all manner of
> build scripts, documentation, source code and schemes for
> automatically incrementing the universe on a version change created my
> Oracle's customers and users.

Has Oracle used anything besides 1.major.minor_update?

Arne

[toc] | [prev] | [next] | [standalone]

#30778

On Wed, 21 Jan 2015 21:13:53 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>Has Oracle used anything besides 1.major.minor_update?

Lately we have jumps e.g. 1.8.0_25 -> 1.8.0_31

We now have a version sometimes labelled 74/75.

At the most you need XX.YY where XX is a major released with new
features, and YY is a bug fix release.

So 1.8.0_32 would be 8.32. However stability is more important than
brevity.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
To solve an interesting problem, start by finding a problem
that is interesting to you.
~ Eric S. Raymond (born: 1957-12-04 age: 57)

[toc] | [prev] | [next] | [standalone]

#30804

On 1/21/2015 9:53 PM, Roedy Green wrote:
> On Wed, 21 Jan 2015 21:13:53 -0500, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> Has Oracle used anything besides 1.major.minor_update?
>
> Lately we have jumps e.g. 1.8.0_25 -> 1.8.0_31
>
> We now have a version sometimes labelled 74/75.
>
> At the most you need XX.YY where XX is a major released with new
> features, and YY is a bug fix release.
>
> So 1.8.0_32 would be 8.32. However stability is more important than
> brevity.

<http://semver.org/> is the emerging standard for versioning. In short:
X.y.z-w
An increase in X indicates a backwards-incompatible change. Code that 
compiles with, e.g., 1.4.0 will not necessarily compile with 2.4.0
An increase in Y indicates a major, but backwards-compatible change. 
Code that compiles with 1.4.0 will compile with 2.0.0, but not 
necessarily vice versa.
An increase in Z is a "bugfix" update: code that compiles with 1.4.1 
will work with 1.4.0.
The w qualifier is extra gunk that may be needed for build processes or 
prerelease.

As Java is unlikely to ever break backwards compatibility, that first 
digit is probably going to stay 1 forever.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#30805

On Thu, 22 Jan 2015 11:36:37 -0600, Joshua Cranmer 🐧 wrote:

> <http://semver.org/> is the emerging standard for versioning. In short:
> X.y.z-w An increase in X indicates a backwards-incompatible change. Code
> that compiles with, e.g., 1.4.0 will not necessarily compile with 2.4.0
> An increase in Y indicates a major, but backwards-compatible change.
> Code that compiles with 1.4.0 will compile with 2.0.0, but not
> necessarily vice versa.
> An increase in Z is a "bugfix" update: code that compiles with 1.4.1
> will work with 1.4.0.
> The w qualifier is extra gunk that may be needed for build processes or
> prerelease.
> 
> As Java is unlikely to ever break backwards compatibility, that first
> digit is probably going to stay 1 forever.
>
That is a useful reference. Thanks for posting it.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#30934

On Thu, 22 Jan 2015 11:36:37 -0600, Joshua Cranmer ?
<Pidgeot18@verizon.invalid> wrote, quoted or indirectly quoted someone
who said :

><http://semver.org/> is the emerging standard for versioning.

That makes sense. It is still missing the ability to judge how old
software is just from its version number. That could be handled by
quoting the release date any time you quote the version number.

I have added an entry to the java glossary at
http://mindprod.com/jgloss/semanticversioning.html

I took your work, formatted it,  and corrected a few minor errors.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
To solve an interesting problem, start by finding a problem
that is interesting to you.
~ Eric S. Raymond (born: 1957-12-04 age: 57)

[toc] | [prev] | [next] | [standalone]

#30938

On Mon, 26 Jan 2015 21:23:16 -0800, Roedy Green wrote:

> It is still missing the ability to judge how old
> software is just from its version number.
>
I definitely want to know whether a new version retains backward 
compatibility or not and what, if anything, is deprecated, but if a 
version is bug-free, why should I care when it was released? 

As a concrete example, I have programs that I use regularly that depend 
on termcap for terminal handling. The latest version of GNU termcap is 
1.3.1 and its manpage says it was last released in 1996. It has no bugs 
that I've ever discovered. I last compiled it in 2013 - with no errors - 
and it works just fine, so why would I care when that version was 
released: I've never known its release date before and looked it up just 
so I could quote it here.
  

I'm really mystified about why you think the release date has any 
significance.

BTW, I notice that you haven't included a link to semver.org in your 
glossary entry. Why not? Its a top-level URL for that domain, so unlikely 
to change, and as its well worth reading the document it references, 
adding a link would be a good thing to do.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#30845

On 1/21/2015 10:53 PM, Roedy Green wrote:
> On Wed, 21 Jan 2015 21:13:53 -0500, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> Has Oracle used anything besides 1.major.minor_update?
>
> Lately we have jumps e.g. 1.8.0_25 -> 1.8.0_31

It is the same version number convention.

The parts are increasing properly.

If a tool breaks because a part is increased by more
than 1, then I think that tools has a design flaw.

> We now have a version sometimes labelled 74/75.

Oracle has documented why they release two versions
in parallel.

Arne

[toc] | [prev] | [next] | [standalone]

#30846

On 1/24/2015 9:27 PM, Arne Vajhøj wrote:
>[...]
> If a tool breaks because a part is increased by more
> than 1, then I think that tools has a design flaw.

     Would you mind explaining this further?  It seems that you're
saying

	"If a tool breaks because a part's version increments by 1
	that's all right."

	"If a tool breaks because a part's version increments by
	2,3,4,...,1e100,... that's a design flaw."

I'm sure that's not what you mean -- but what *do* you mean?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#30847

On 1/24/2015 10:07 PM, Eric Sosman wrote:
> On 1/24/2015 9:27 PM, Arne Vajhøj wrote:
>> [...]
>> If a tool breaks because a part is increased by more
>> than 1, then I think that tools has a design flaw.
>
>      Would you mind explaining this further?  It seems that you're
> saying
>
>      "If a tool breaks because a part's version increments by 1
>      that's all right."
>
>      "If a tool breaks because a part's version increments by
>      2,3,4,...,1e100,... that's a design flaw."
>
> I'm sure that's not what you mean -- but what *do* you mean?

The claim made by Roedy in my interpretation was that:
* increments of 1 works
* increments of N where N > 1 break things

And may claim is that I consider the last case to be a
tool problem not an Oracle problem.

Increments of 1 breaking things was not being discussed at
all.

And besides in general X => Y does not imply that NOT X => NOT Y.

Arne

[toc] | [prev] | [next] | [standalone]

#30936

On Sat, 24 Jan 2015 22:07:02 -0500, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote, quoted or indirectly quoted
someone who said :

>I'm sure that's not what you mean -- but what *do* you mean?

There is no need to increment version numbers by other than one.  It
erroneously makes people think they have been missing updates.

If for example you planned to release a version then changed your
mind, when you do finally get around to releasing, the public need not
know about that aborted internal release. You can still increment by 1
instead of 2.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
To solve an interesting problem, start by finding a problem
that is interesting to you.
~ Eric S. Raymond (born: 1957-12-04 age: 57)

[toc] | [prev] | [next] | [standalone]

#30937

On Mon, 26 Jan 2015 21:29:32 -0800, Roedy Green wrote:

> On Sat, 24 Jan 2015 22:07:02 -0500, Eric Sosman
> <esosman@comcast-dot-net.invalid> wrote, quoted or indirectly quoted
> someone who said :
>>I'm sure that's not what you mean -- but what *do* you mean?
> There is no need to increment version numbers by other than one.  It
> erroneously makes people think they have been missing updates.

> If for example you planned to release a version then changed your
> mind, when you do finally get around to releasing, the public need not
> know about that aborted internal release. You can still increment by 1
> instead of 2.

You don't know what internal requirements I/someone has. Maybe I did fnish
the planned version, but didn't release it for whatever reason. The public
may not NEED to know about the internal release, but I see no reason to go
out of my way to hide it by restructuring my internal processes to deal
with two physically different versions that have the same version number
just because someone out there may, uh, worry about having missed updates. 

Is that even a thing ? Do people actually compare new versions of things to
their old versions and then worry when 17.12 of something updates to 17.14
instead of 17.13 ? Quite frankly, that seems insane, and the added burden
of having multiple internal versions with the same version number just to
prevent that sounds totally lunatic.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#30987

On 1/27/2015 12:29 AM, Roedy Green wrote:
> On Sat, 24 Jan 2015 22:07:02 -0500, Eric Sosman
> <esosman@comcast-dot-net.invalid> wrote, quoted or indirectly quoted
> someone who said :
>
>> I'm sure that's not what you mean -- but what *do* you mean?
>
> There is no need to increment version numbers by other than one.


Almost everything does that.

Java has done so for more than a decade.

MS build numbers jumps way more than 1.

Linux kernel numbers occasionally jumps more than 1.

 >                                                                  It
 > erroneously makes people think they have been missing updates.

Those people would be puzzled all the time.

But let us say that such people exist, then what - you want the latest 
anyway.

> If for example you planned to release a version then changed your
> mind, when you do finally get around to releasing, the public need not
> know about that aborted internal release. You can still increment by 1
> instead of 2.

That would be extremely bad software engineering.

A given release has a given version number. If bugs are found during
test and a release never get release to the public, then you do not
never ever reuse the version number for the next release. Doing so
would given enough time guarantee that the wrong version of version X
get released.

Arne

[toc] | [prev] | [next] | [standalone]

#30853

Arne Vajhøj <arne@vajhoej.dk> writes:
> On 1/21/2015 10:53 PM, Roedy Green wrote:

>> Lately we have jumps e.g. 1.8.0_25 -> 1.8.0_31

> If a tool breaks because a part is increased by more
> than 1, then I think that tools has a design flaw.

Definitely.
New fixes for such tools couldn't be released before absolutely every
user of them have upgraded to the newest version.
Even when another little fast-to-fix bug is found just after a release
and just a few people have upgraded, and the first upgrader reported the
bug.

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

#30893

Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> writes:
> Arne Vajhøj <arne@vajhoej.dk> writes:

>> If a tool breaks because a part is increased by more
>> than 1, then I think that tools has a design flaw.

> New fixes for such tools couldn't be released before absolutely every
> user of them have upgraded to the newest version.

Or at least, whenever more than one upgrade has been released, everybody
would need to go through ALL of them instead of just upgrading with the
latest one.

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

#30935

On Sat, 24 Jan 2015 21:27:41 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote, quoted or indirectly quoted someone who said :

>Oracle has documented why they release two versions
>in parallel.

They should simply have released two versions logically one right
after the other with explanations, not have partially broken the
numbering system.

For users, then it simply becomes a matter of ignoring one of the two
releases which will not break any scripts.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
To solve an interesting problem, start by finding a problem
that is interesting to you.
~ Eric S. Raymond (born: 1957-12-04 age: 57)

[toc] | [prev] | [next] | [standalone]

#30986

On 1/27/2015 12:25 AM, Roedy Green wrote:
> On Sat, 24 Jan 2015 21:27:41 -0500, Arne Vajhøj <arne@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> Oracle has documented why they release two versions
>> in parallel.
>
> They should simply have released two versions logically one right
> after the other with explanations, not have partially broken the
> numbering system.

Isn't that what they did?

They released two versions. And I am sure there were some time interval
in between - milliseconds or days does not change the concept.

They provided an explanation.

The version numbers were following existing scheme and did increase.

What else could they possible do?

> For users, then it simply becomes a matter of ignoring one of the two
> releases which will not break any scripts.

I think that is what everybody did. They decided whether to take u75
or u76.

Arne

[toc] | [prev] | [next] | [standalone]

#30775

On 1/20/2015 8:16 PM, Roedy Green wrote:
> On Tue, 20 Jan 2015 17:10:23 -0800, Roedy Green
> <see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
> someone who said :
>
>> JDK 1.7.0_75 and JDK 1.8.0_31 are out
>>
>> 1.7.0_76 in April will be the end of JDK  1.7. Autoupdate will flip
>> 1.7 to 1.8.
>
> There is some confusion about 1.7.0_76.
> The executable is called 1.7.0_75
> The release notes for the current version are 1.7.0_76.
>
> There was once a time when versions were simple sequential numbers.

That is a long time ago.

1.4 has jumps in update numbers.

Arne

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web