Accelerating the JDK release cadence (original) (raw)

Jonathan Bluett-Duncan jbluettduncan at gmail.com
Thu Sep 7 19:12:28 UTC 2017

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

More information about the discuss mailing list