+1
What is the Apache way? If there are no strict guidelines as to how
Apache projects are supposed to release, then I vote we an existing
"standard".
--Udo
On 1/8/16 10:48 AM, John Blum 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)
