+1 I agree to follow the Spring model (Mx, RCx, RELEASE), which will be
inline with following the Maven publishing guidelines. As for using M1, M2,
M3 vs ALPHA, BETA for other Apache projects, I took a quick look and seems
to be divided.

We haven't released yet, so not too late right? Whatever strategy/schema we
go with for the upcoming release, we will more or less 'lock' ourselves
into through the 1.0.0 and possibly longer. So getting consensus now will
save headaches later.

--Mark

On Fri, Jan 8, 2016 at 11:29 AM, William Markito <[email protected]>
wrote:

> +1
>
> On Fri, Jan 8, 2016 at 11:04 AM, Kirk Lund <[email protected]> wrote:
>
> > I prefer the Spring model on release numbering/labeling. Also since I'm
> one
> > of the folks who has to work on both projects, I really want this to be
> > consistent between Apache Geode (incubating) and Spring Data GemFire.
> >
> > -Kirk
> >
> >
> > On Fri, Jan 8, 2016 at 10:58 AM, Swapnil Bawaskar <[email protected]>
> > wrote:
> >
> > > > Also, I don’t see a need to do M? or RC? releases before this initial
> > > release.
> > >
> > > I think we could have called this release M1 (our first milestone of
> > > removing olg jgroups and cleanup) rather than alpha1. But it probably
> is
> > > too late to change that now.
> > >
> > > On Fri, Jan 8, 2016 at 10:48 AM, John Blum <[email protected]> wrote:
> > >
> > > > For clarification, the "RELEASE" version qualifier is only used for
> the
> > > > final GA (production-grade release), not any other version.  So, by
> way
> > > of
> > > > example, (using Spring Data GemFire
> > > > <https://github.com/spring-projects/spring-data-gemfire/releases>
> [0])
> > > the
> > > > release series will progress as follows...
> > > >
> > > > 1.7.0.M1
> > > > 1.7.0.RC1
> > > > 1.7.0.RELEASE
> > > > 1.7.1.RELEASE
> > > > 1.7.2.RELEASE
> > > > 1.8.0.M1
> > > > 1.8.0.RC1
> > > > 1.8.0.RELEASE
> > > >
> > > > There can be any number of milestone and release candidates in
> between.
> > > >
> > > > With Spring, rather than having alpha, beta, etc type releases, we
> just
> > > use
> > > > milestones (which implies things are changing... feature additions,
> > > > enhancements, bug fixes, etc) while release candidates indicate
> > hardening
> > > > of the release version (mainly bug fixes, perhaps minor enhancements
> > that
> > > > won't destabalize the build) and final RELEASE of course, indicates,
> it
> > > is
> > > > ready for production.
> > > >
> > > > Hope this helps.
> > > >
> > > > -John
> > > >
> > > > [0] -
> https://github.com/spring-projects/spring-data-gemfire/releases
> > > >
> > > >
> > > > On Fri, Jan 8, 2016 at 10:22 AM, Anthony Baker <[email protected]>
> > > wrote:
> > > >
> > > > > As a starting point for discussion, I’ve set the version on the
> > > > > release/1.0.0-incubating-alpha1 branch to:
> > > > >
> > > > >         1.0.0-incubating-alpha1
> > > > >
> > > > > Is there a preference to follow the Spring convention as John is
> > > > > suggesting?  Are there many / any ASF projects following that
> > > > convention?.
> > > > > Here’ s what that version string would look like:
> > > > >
> > > > >         1.0.0-incubating-alpha1.RELEASE
> > > > >
> > > > >
> > > > > I do think we should remove the -SNAPSHOT from the version on the
> > > release
> > > > > branch so that we can validate the exact bits that we will publish.
> > > > Also,
> > > > > I don’t see a need to do M? or RC? releases before this initial
> > > release.
> > > > > IMHO of course...
> > > > >
> > > > > Anthony
> > > > >
> > > > >
> > > > > > On Jan 8, 2016, at 9:44 AM, John Blum <[email protected]> wrote:
> > > > > >
> > > > > > In Spring, the releaseType (qualifier) is always (BUILD-)SNAPSHOT
> > > > unless
> > > > > it
> > > > > > is a release (M1, M2, ..., RC1, ... RELEASE (GA)).
> > > > > >
> > > > > > When a particular version ends, for instance when 1.0.0.RELASE
> goes
> > > GA,
> > > > > the
> > > > > > version/releaseType switches to 1.1.0.(BUILD-)SNAPSHOT and a
> 1.0.x
> > > > branch
> > > > > > is created to "service" the old version (with subsequent releases
> > > being
> > > > > > 1.0.1.RELEASE, 1.0.2.RELEASE, etc; the 1.0.x development branch
> > will
> > > > have
> > > > > > then have subsequent versions of 1.0.3.(BUILD-)SNAPSHOT), but
> > remain
> > > > > with a
> > > > > > releaseType of (BUILD-)SNAPSHOT).
> > > > > >
> > > > > > Make sense?
> > > > > >
> > > > > >
> > > > > > On Fri, Jan 8, 2016 at 8:26 AM, William Markito <
> > [email protected]
> > > >
> > > > > wrote:
> > > > > >
> > > > > >> I think we can keep it snapshot until it actually becomes a
> final
> > > > > >> release...  Ideally it would go - *SNAPSHOT -> BETA, RC,
> RC2.... -
> > > > > >> Release* -
> > > > > >> but by keeping it snapshots until the "final" release will
> > probably
> > > > easy
> > > > > >> the process, unless ASF requires otherwise.
> > > > > >>
> > > > > >> By the way, I'm looking into this -
> > > > > >> https://github.com/researchgate/gradle-release and not sure we
> > > > already
> > > > > use
> > > > > >> that in our scripts.
> > > > > >>
> > > > > >>
> > > > > >> On Wed, Jan 6, 2016 at 6:04 PM, Anthony Baker <
> [email protected]>
> > > > > wrote:
> > > > > >>
> > > > > >>> I was looking in our gradle.properties file:
> > > > > >>>
> > > > > >>>        versionNumber = 1.0.0-incubating
> > > > > >>>        releaseType = SNAPSHOT
> > > > > >>>
> > > > > >>> I’m not sure what the releaseType should be for a non-SNAPSHOT
> > > > release
> > > > > >> :-)
> > > > > >>>
> > > > > >>> Given that version is set to:
> > > > > >>>
> > > > > >>>        version = versionNumber + '-' + releaseType
> > > > > >>>
> > > > > >>> I'm wondering if we should just simplify this and set the
> version
> > > > > >> directly
> > > > > >>> in the properties file.
> > > > > >>>
> > > > > >>> Thoughts?
> > > > > >>>
> > > > > >>> Anthony
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >>
> > > > > >> William Markito Oliveira
> > > > > >> -- For questions about Apache Geode, please write to
> > > > > >> *[email protected]
> > > > > >> <[email protected]>*
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > -John
> > > > > > 503-504-8657
> > > > > > john.blum10101 (skype)
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > -John
> > > > 503-504-8657
> > > > john.blum10101 (skype)
> > > >
> > >
> >
>
>
>
> --
>
> William Markito Oliveira
> -- For questions about Apache Geode, please write to
> *[email protected]
> <[email protected]>*
>

Reply via email to