Accelerating the JDK release cadence

[Jonathan Bluett-Duncan]

>
> 2. Every product that has used time-based version numbers has inevitably
> dropped the approach (the only exception that comes to mind is MS Word).
> When this happens, the version history is permanently polluted with large
> version numbers. Instead of hijacking the major.minor version numbers,
> consider placing this information in the build number (e.g.
> 9.1.5+2017-11-15)


Oh, really? I thought that Ubuntu and IntelliJ IDEA still follow a
time-based version scheme.

Cheers,
Jonathan

On 7 September 2017 at 20:04, cowwoc <cowwoc at bbs.darktech.org> wrote:

> While I like the idea of more frequent releases, I see two problems with
> the
> proposal in its current form:
>
> 1. It takes longer than 6 months for users to expose design problems.
> Consider tagging new features with @Beta annotations, allowing the breaking
> of backward compatibility for another year or so, and eventually graduating
> them to stability by removing the @Beta tags.
>
> 2. Every product that has used time-based version numbers has inevitably
> dropped the approach (the only exception that comes to mind is MS Word).
> When this happens, the version history is permanently polluted with large
> version numbers. Instead of hijacking the major.minor version numbers,
> consider placing this information in the build number (e.g.
> 9.1.5+2017-11-15)
>
> Gili
>
>
>
> --
> Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-General-
> discussion-f67169.html
>