+1

On Mon, Jan 11, 2016 at 11:08 AM, John Blum <jb...@pivotal.io> wrote:

> +1
>
> On Mon, Jan 11, 2016 at 10:19 AM, Anthony Baker <aba...@pivotal.io> wrote:
>
> > Sounds like the consensus is to use the Spring conventions (note that we
> > can always change later…most projects I surveyed have evolved their
> release
> > naming over time).  Shall we also adopt Swapnil’s suggestion to change
> from
> > alpha1 to M1?  That is:
> >
> >         1.0.0-incubating.M1
> >
> > Anthony
> >
> >
> >
> > > On Jan 8, 2016, at 7:36 PM, Niall Pemberton <niall.pember...@gmail.com
> >
> > wrote:
> > >
> > > On Sat, Jan 9, 2016 at 3:06 AM, Roman Shaposhnik <ro...@shaposhnik.org
> >
> > > wrote:
> > >
> > >> Note, that in ASF the RCs are NOT published into public Maven
> > >> repo and are generally not disclosed ouside of the dev. community.
> > >>
> > >
> > > I think in this discussion the proposal is to use "RC" in the version
> of
> > an
> > > official ASF release (e.g. "1.0.0-RC1") - if thats the case it
> > could/would
> > > be published to the public Maven repo and advertised outside the dev
> > > community.
> > >
> > > Niall
> > >
> > >
> > >>
> > >> Thanks,
> > >> Roman.
> > >>
> > >> On Fri, Jan 8, 2016 at 10:48 AM, John Blum <jb...@pivotal.io> 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 <aba...@pivotal.io>
> > >> 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 <jb...@pivotal.io> 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 <
> wmark...@pivotal.io
> > >
> > >>>> 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 <aba...@pivotal.io>
> > >>>> 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
> > >>>>>> *dev@geode.incubator.apache.org
> > >>>>>> <dev@geode.incubator.apache.org>*
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> -John
> > >>>>> 503-504-8657
> > >>>>> john.blum10101 (skype)
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> -John
> > >>> 503-504-8657
> > >>> john.blum10101 (skype)
> > >>
> >
> >
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>

Reply via email to