Gives the whole idea of release management a new meaning
Now you will have to come up with a process to ensure that you don't release
windows 2016 in 2017 :)
Or have a process where the internal version numbers only get assigned after
the last beta :)
So anyone doing a beta doesn't know what version they are testing.. just in
case the release bleeds into next year
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Mladen Gogala
Sent: Thursday, July 13, 2017 9:38 PM
To: Tim Gorman
Cc: oracle-l
Subject: Re: New SQL*Developer version numbers
Hi Tim!
Year based releases? What a marvelously elegant idea! Release "Oracle SQL
Server 2018" would avoid all the problems of the unlucky number 13. Hopefully,
another vendor who also has year based release names, will not release SQL
Server 2018. Maybe they should have an even-odd release system, just like
parking in NYC?
Regards
On Thu, 13 Jul 2017 16:31:19 -0600
Tim Gorman <tim.evdbt@xxxxxxxxx> wrote:
Perhaps Oracle is going to year-based releases?
Neatly sidesteps all the "what comes after Oracle12" nonsense.
On 7/13/17 16:20, Mladen Gogala wrote:
On July the 11th, there was an update to SQL*Developer and SQLcl. The
previous version was 4.2. Now, I see this:
SQLcl: Release 17.2.0 Production on Thu Jul 13 18:16:30 2017
Copyright (c) 1982, 2017, Oracle. All rights reserved.
SQL>
Version "17.2"? Really? How did that happen? The same applies to
SQL*Developer. Functionality is still pretty much the same, I haven't
encountered any problems yet.
Regards