+1

On Mon, Jan 11, 2016 at 10:19 AM, Anthony Baker <[email protected]> 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 <[email protected]>
> wrote:
> >
> > On Sat, Jan 9, 2016 at 3:06 AM, Roman Shaposhnik <[email protected]>
> > 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 <[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)
> >>
>
>


-- 
-John
503-504-8657
john.blum10101 (skype)

Reply via email to