trafodion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Varnau <steve.var...@esgyn.com>
Subject RE: Apache Trafodion release
Date Wed, 20 Jan 2016 22:36:25 GMT
The "release candidate" versions of software are not releases, so we don't
change the release number.  We do create tags for those pre-release
versions, such as 1.3.0rc2 for the second release candidate for 1.3.0.  The
final tag for the release does not have such a suffix.

Then if we have "patch" releases, where we back-port specific fixes onto
that branch and do a new release, then we increment the third (update)
number.  So we have major.minor.update.

In addition, we usually talk about certain features being at alpha or beta,
but the release itself should be solid by the time we complete the release
process, right?

Also, I think it is not wise to expect that every release takes a set number
of iterations to reach final status. Why is three the magic number?  Some
releases take one or two release candidates, others may take many.

--Steve


> -----Original Message-----
> From: Gunnar Tapper [mailto:tapper.gunnar@gmail.com]
> Sent: Wednesday, January 20, 2016 12:20 PM
> To: dev@trafodion.incubator.apache.org
> Subject: Re: Apache Trafodion release
>
> Hi,
>
> Call the 2.0.0 change a ship that has sailed and then implement a more
> defined release-numbering scheme moving forward? 2.0.0 would be the alpha
> release, 2.0.1 beta and so on.
>
> It might be a good idea to define some rules regarding rolling of the
> major
> and minor numbers, too. For example:
>
> major-release.minor-release.release-status
>
> major-release: changes when major incompatibilities are introduced. End
> users are recommended to do full regression testing before using this
> release.
> minor-release: changes when a batch of new features are installed. No
> major
> compatibility issues are expected. End users are recommended to basic
> regression testing before using this release.
> release-status: represents the status of the released: 0 = alpha, 1 =
> beta,
> 2 = release candidate, 3 = (final) release.
>
> Build number and date matters within release status; that is, there can be
> several iterations for the different release-status leading up to x.x.3
>
> Thanks,
>
> Gunnar
>
> Thanks,
>
> Gunnar with a past in release-model definitions
>
> On Wed, Jan 20, 2016 at 11:31 AM, Steve Varnau <steve.varnau@esgyn.com>
> wrote:
>
> > When we branched the 1.3 release, I updated release number on the master
> > branch. At that time I proposed 2.0.0 for next release. I saw no
> > objections
> > on this list, so that was what was implemented.  I guess we could go
> > backward to a lower number if there is a compelling reason, but the
> > simplest
> > at this point is to stick with 2.0.0.
> >
> > --Steve
> >
> >
> > > -----Original Message-----
> > > From: Gunnar Tapper [mailto:tapper.gunnar@gmail.com]
> > > Sent: Wednesday, January 20, 2016 10:24 AM
> > > To: dev@trafodion.incubator.apache.org
> > > Subject: Re: Apache Trafodion release
> > >
> > > Hi,
> > >
> > > On Software Version: https://en.wikipedia.org/wiki/Software_versioning
> > >
> > > The Designated Development State (
> > >
> >
> https://en.wikipedia.org/wiki/Software_versioning#Designating_development_s
> > > tage)
> > > makes a lot of sense IMO:
> > >
> > >
> > >    - 0 for alpha (status)
> > >    - 1 for beta (status)
> > >    - 2 for release candidate
> > >    - 3 for (final) release
> > >
> > >    Simple to understand.
> > >
> > >
> > >
> > > On Wed, Jan 20, 2016 at 9:10 AM, Roberta Marton
> > > <roberta.marton@esgyn.com>
> > > wrote:
> > >
> > > > My term as Release Manager for Apache Trafodion release 1.3.0 has
> been
> > > > completed.  Kudos to everyone who made it possible.
> > > >
> > > > The Apache Trafodion team is now planning its next release and is
> > > > looking
> > > > for input from the community. We would like to release the next
> > > > version
> > > > of
> > > > Trafodion in 6 to 8 weeks. To make this happen, we would like:
> > > >
> > > > 1.       Someone to volunteer to be the Release Manager
> > > >
> > > > 2.       Advice in determining release content.  The following are
> > > > some
> > > > suggestions, please reply with any comments, additions or deletions?
> > > >
> > > > a.       Release binaries along with the source tar file
> > > >
> > > > b.      Build and run on Vanilla Apache releases (TRAFODION-1484).
> > > > Any
> > > > recommendations on what versions we should target?  Hadoop release
> > 2.6.?
> > > > and HBase 1.1.?
> > > >
> > > > c.       Fix the licensing issues requested by the IPMC team during
> > > > our
> > > > last release
> > > >
> > > >                                                                i.
> > > > TRAFODION-1725
> > > > – Missing license information
> > > >
> > > >                                                              ii.
> > > > TRAFODION-1733
> > > > - Incorrect information included in LICENSE file
> > > >
> > > >                                                             iii.
> > > > TRAFODION-1734
> > > > – Improvements to licensing information
> > > >
> > > >                                                            iv.
> > > > TRAFODION-1735
> > > > – Verify copyright information for files changed by Trafodion
> > > >
> > > > d.      Improve the build process – some candidates:
> > > >
> > > >                                                                i.
> > > > TRAFODION-1522
> > > > – Consolidate HBase version requirements in Trafodion build
> > > >
> > > >                                                              ii.
> > > > TRAFODION-1614
> > > > – Improve performance of traf_tools_setup script
> > > >
> > > >                                                             iii.
> > > > TRAFODION-1704
> > > > – T2 and T4 driver cleanup
> > > >
> > > >                                                            iv.
> > > > TRAFODION-1749
> > > > – Unable to build or run Trafodion because of missing log4cxx files
> > > >
> > > >                                                              v.
> > (no
> > > > JIRA) Fix problem with parallel builds
> > > >
> > > > 3.       Versioning guidelines.  What should our new release version
> > be?
> > > > Apache products seem to implement different ways of versioning their
> > > > releases.  Some suggestions for the next release:
> > > >
> > > > a.       1.3.5
> > > >
> > > > b.      1.4.0
> > > >
> > > > c.       2.0.0
> > > >
> > > >    Regards,
> > > >
> > > >    Roberta
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks,
> > >
> > > Gunnar
> > > *If you think you can you can, if you think you can't you're right.*
> >
>
>
>
> --
> Thanks,
>
> Gunnar
> *If you think you can you can, if you think you can't you're right.*

Mime
View raw message