You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2011/06/28 18:22:05 UTC
[DISCUSS] Proposal for New Versioning Procedures
Tapestry versioning structure as currently implemented in problematic
for several reasons:
1. We vote and release non-final artifacts, which goes against the
established model set by the board.
2. We have a proliferation of version numbers, which complicates the
creation of builds, as well as tracking in JIRA.
3. Strictly numeric version numbers require a separate lookup in
documentation to establish stability (alpha, beta, release candidate,
final).
The latter has been seen recently with people thinking that version
5.3.0 is a final build, rather than a very early alpha build.
This proposal would simplify the version numbering scheme and link it
properly to the release numbering scheme, while preserving efforts to
ensure that final releases are available to a wide audience before
being voted as final.
Tapestry version numbers for stable releases will henseforth match
Tapestry release numbers. A release number consists of a product
number (5) and a index number (for example, 3) separated by a dot. At
the time of this writing, the stable release number is "5.2" and the
development release number is "5.3".
A bug fix release replaces a stable release, adding an index number to
the release number. Thus the first bug fix release of Tapestry 5.3
will be Tapestry 5.3.1, followed by 5.3.2, etc. (as necessary).
Only final, stable releases will be made widely available (via the
Apache downloads page, or via the central Maven repository).
Intermediate artifacts represent previews of the eventual stable
release. The version number for such a preview is of the form
"<release-number>-<stability>-<index>", where the release number is as
described above, the stability is one of "alpha", "beta" or "rc", and
the index number indicates the order within the stability. The index
number starts at 1.
"alpha" releases are not stable; the represent functionality in flux;
classes and methods may be renamed or otherwise refactored between
releases.
"beta" releases occur once main functionality is complete; they exist
to fix bug in old and new functionality, and fill and gaps in
functionality.
"rc" releases are "release candidates"; the functionality should be
solid; the point of a release candidate is to get wide exposure to the
new codebase to ensure that the final release is free of bugs.
A preview release may be created at any time. A tag is created in
Subversion to label the extact source from which the preview release
is generated. The preview release is built and uploaded to the Apache
Nexus. Once uploaded, the master version number should be advanced to
the next index number within the same stability series (example:
"5.3-alpha-2" to "5.3-alpha-3").
Following a lazy-consensus vote, the URL for the preview release may
be distributed on the Tapestry user mailing list. However, preview
releases are deleted, not released. This is important ... preview
releases are never released to the Maven Central repository, only
final releases are distributed via Maven Central.
A stability vote may follow a successful preview release vote. This is
to vote the code base up to the next level of stability (to "beta",
then "rc", then "final"). This is also a lazy consensus vote.
Once a release is final, a final release may be built and uploaded to
the Apache Nexus. A final release also includes additional non-Maven
artifacts containing the project's source code, and additional
artifacts containing JavaDoc or other reports.
The final vote for a release is a binding vote, requiring at least 3
+1 votes and no vetoes, as outlined in
http://www.apache.org/foundation/voting.html
Following a successful release vote, the final release artifacts in
the Apache Nexus repository may be released to the Maven Central
repository, and the additional artifacts moved into place for download
from the Apache distribution mirrors. This is also the point at which
the Tapestry wiki is updated to announce the new release (and provide
proper links to it), as well as announcements on the Tapestry user
mailing list and elsewhere.
Bug fix releases are follow-ons to stable releases. Bug fix releases
automatically start at stability "rc", reflecting the fact that only
localized bug fixes are expected to be included in such a release.
Once all desired bug fixes are in place, a stability vote (to "final")
is followed by a release vote.
PROS:
At-a-glance identification of version stability.
Alignment of Tapestry product releases ("5.3") with Tapestry version
numbers ("5.3", then "5.3.1").
Streamlined procedures for generating and distributing a preview release.
Simplification of issue tracking in JIRA.
Most votes can be lazy-consensus.
CONS:
People desiring early access must search the correct Nexus repository;
this will limit the exposure of preview releases.
More voting, as stability votes are separate from preview and final
release votes.
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] Proposal for New Versioning Procedures
Posted by Bob Harner <bo...@gmail.com>.
I like it.
Bob Harner
On Jun 28, 2011 2:58 PM, "Thiago H. de Paula Figueiredo" <th...@gmail.com>
wrote:
> On Tue, 28 Jun 2011 15:51:16 -0300, Andreas Andreou <an...@gmail.com>
> wrote:
>
>> The suggested new process is nicely documented and surely improves
>> on what we had back then. So, my first reaction is possitive ... My
>> problem though is that when i start tearing it to pieces it doesn't feel
>> much different than the current one (and thus worth it).
>
> The difference is basically adding suffixes to non-stable releases
> versions (alpha, beta, release candidate).
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
Re: [DISCUSS] Proposal for New Versioning Procedures
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 28 Jun 2011 15:51:16 -0300, Andreas Andreou <an...@gmail.com>
wrote:
> The suggested new process is nicely documented and surely improves
> on what we had back then. So, my first reaction is possitive ... My
> problem though is that when i start tearing it to pieces it doesn't feel
> much different than the current one (and thus worth it).
The difference is basically adding suffixes to non-stable releases
versions (alpha, beta, release candidate).
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] Proposal for New Versioning Procedures
Posted by Andreas Andreou <an...@gmail.com>.
Tapestry 4.0 was released under a similar scheme (alpha, betas and rcs)
which was then abandoned in 4.1 and 5.0, 5.1, 5.2. I don't remember if that was
just experimentation or if there were genuine reasons for that change.
The suggested new process is nicely documented and surely improves
on what we had back then. So, my first reaction is possitive ... My
problem though is that when i start tearing it to pieces it doesn't feel
much different than the current one (and thus worth it).
So, anyway, if this were a vote, i'd be +0
On Tue, Jun 28, 2011 at 20:57, Ulrich Stärk <ul...@spielviel.de> wrote:
>
>
> On 28.06.2011 18:22, Howard Lewis Ship wrote:
>> Tapestry versioning structure as currently implemented in problematic
>> for several reasons:
>> 1. We vote and release non-final artifacts, which goes against the
>> established model set by the board.
>> 2. We have a proliferation of version numbers, which complicates the
>> creation of builds, as well as tracking in JIRA.
>> 3. Strictly numeric version numbers require a separate lookup in
>> documentation to establish stability (alpha, beta, release candidate,
>> final).
>>
>> The latter has been seen recently with people thinking that version
>> 5.3.0 is a final build, rather than a very early alpha build.
>>
>> This proposal would simplify the version numbering scheme and link it
>> properly to the release numbering scheme, while preserving efforts to
>> ensure that final releases are available to a wide audience before
>> being voted as final.
>>
>> Tapestry version numbers for stable releases will henseforth match
>> Tapestry release numbers. A release number consists of a product
>> number (5) and a index number (for example, 3) separated by a dot. At
>> the time of this writing, the stable release number is "5.2" and the
>> development release number is "5.3".
>>
>> A bug fix release replaces a stable release, adding an index number to
>> the release number. Thus the first bug fix release of Tapestry 5.3
>> will be Tapestry 5.3.1, followed by 5.3.2, etc. (as necessary).
>>
>> Only final, stable releases will be made widely available (via the
>> Apache downloads page, or via the central Maven repository).
>>
>> Intermediate artifacts represent previews of the eventual stable
>> release. The version number for such a preview is of the form
>> "<release-number>-<stability>-<index>", where the release number is as
>> described above, the stability is one of "alpha", "beta" or "rc", and
>> the index number indicates the order within the stability. The index
>> number starts at 1.
>>
>> "alpha" releases are not stable; the represent functionality in flux;
>> classes and methods may be renamed or otherwise refactored between
>> releases.
>>
>> "beta" releases occur once main functionality is complete; they exist
>> to fix bug in old and new functionality, and fill and gaps in
>> functionality.
>>
>> "rc" releases are "release candidates"; the functionality should be
>> solid; the point of a release candidate is to get wide exposure to the
>> new codebase to ensure that the final release is free of bugs.
>>
>> A preview release may be created at any time. A tag is created in
>> Subversion to label the extact source from which the preview release
>> is generated. The preview release is built and uploaded to the Apache
>> Nexus. Once uploaded, the master version number should be advanced to
>> the next index number within the same stability series (example:
>> "5.3-alpha-2" to "5.3-alpha-3").
>>
>> Following a lazy-consensus vote, the URL for the preview release may
>> be distributed on the Tapestry user mailing list. However, preview
>> releases are deleted, not released. This is important ... preview
>> releases are never released to the Maven Central repository, only
>> final releases are distributed via Maven Central.
>>
>> A stability vote may follow a successful preview release vote. This is
>> to vote the code base up to the next level of stability (to "beta",
>> then "rc", then "final"). This is also a lazy consensus vote.
>>
>> Once a release is final, a final release may be built and uploaded to
>> the Apache Nexus. A final release also includes additional non-Maven
>> artifacts containing the project's source code, and additional
>> artifacts containing JavaDoc or other reports.
>>
>> The final vote for a release is a binding vote, requiring at least 3
>> +1 votes and no vetoes, as outlined in
>> http://www.apache.org/foundation/voting.html
>>
>> Following a successful release vote, the final release artifacts in
>> the Apache Nexus repository may be released to the Maven Central
>> repository, and the additional artifacts moved into place for download
>> from the Apache distribution mirrors. This is also the point at which
>> the Tapestry wiki is updated to announce the new release (and provide
>> proper links to it), as well as announcements on the Tapestry user
>> mailing list and elsewhere.
>>
>> Bug fix releases are follow-ons to stable releases. Bug fix releases
>> automatically start at stability "rc", reflecting the fact that only
>> localized bug fixes are expected to be included in such a release.
>> Once all desired bug fixes are in place, a stability vote (to "final")
>> is followed by a release vote.
>>
>>
>> PROS:
>>
>> At-a-glance identification of version stability.
>> Alignment of Tapestry product releases ("5.3") with Tapestry version
>> numbers ("5.3", then "5.3.1").
>> Streamlined procedures for generating and distributing a preview release.
>> Simplification of issue tracking in JIRA.
>> Most votes can be lazy-consensus.
>>
>> CONS:
>>
>> People desiring early access must search the correct Nexus repository;
>> this will limit the exposure of preview releases.
>> More voting, as stability votes are separate from preview and final
>> release votes.
>
> As I said before, my understanding is that we can omit voting on preview packages since they are no
> releases in the sense of the ASF. A lazy consensus vote is nice though as it keeps the community
> involved.
>
> Otherwise: +1
>
> Uli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Apache Tapestry PMC / http://chesstu.be owner
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] Proposal for New Versioning Procedures
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Tue, Jun 28, 2011 at 10:57 AM, Ulrich Stärk <ul...@spielviel.de> wrote:
>
>
> On 28.06.2011 18:22, Howard Lewis Ship wrote:
>> Tapestry versioning structure as currently implemented in problematic
>> for several reasons:
>> 1. We vote and release non-final artifacts, which goes against the
>> established model set by the board.
>> 2. We have a proliferation of version numbers, which complicates the
>> creation of builds, as well as tracking in JIRA.
>> 3. Strictly numeric version numbers require a separate lookup in
>> documentation to establish stability (alpha, beta, release candidate,
>> final).
>>
>> The latter has been seen recently with people thinking that version
>> 5.3.0 is a final build, rather than a very early alpha build.
>>
>> This proposal would simplify the version numbering scheme and link it
>> properly to the release numbering scheme, while preserving efforts to
>> ensure that final releases are available to a wide audience before
>> being voted as final.
>>
>> Tapestry version numbers for stable releases will henseforth match
>> Tapestry release numbers. A release number consists of a product
>> number (5) and a index number (for example, 3) separated by a dot. At
>> the time of this writing, the stable release number is "5.2" and the
>> development release number is "5.3".
>>
>> A bug fix release replaces a stable release, adding an index number to
>> the release number. Thus the first bug fix release of Tapestry 5.3
>> will be Tapestry 5.3.1, followed by 5.3.2, etc. (as necessary).
>>
>> Only final, stable releases will be made widely available (via the
>> Apache downloads page, or via the central Maven repository).
>>
>> Intermediate artifacts represent previews of the eventual stable
>> release. The version number for such a preview is of the form
>> "<release-number>-<stability>-<index>", where the release number is as
>> described above, the stability is one of "alpha", "beta" or "rc", and
>> the index number indicates the order within the stability. The index
>> number starts at 1.
>>
>> "alpha" releases are not stable; the represent functionality in flux;
>> classes and methods may be renamed or otherwise refactored between
>> releases.
>>
>> "beta" releases occur once main functionality is complete; they exist
>> to fix bug in old and new functionality, and fill and gaps in
>> functionality.
>>
>> "rc" releases are "release candidates"; the functionality should be
>> solid; the point of a release candidate is to get wide exposure to the
>> new codebase to ensure that the final release is free of bugs.
>>
>> A preview release may be created at any time. A tag is created in
>> Subversion to label the extact source from which the preview release
>> is generated. The preview release is built and uploaded to the Apache
>> Nexus. Once uploaded, the master version number should be advanced to
>> the next index number within the same stability series (example:
>> "5.3-alpha-2" to "5.3-alpha-3").
>>
>> Following a lazy-consensus vote, the URL for the preview release may
>> be distributed on the Tapestry user mailing list. However, preview
>> releases are deleted, not released. This is important ... preview
>> releases are never released to the Maven Central repository, only
>> final releases are distributed via Maven Central.
>>
>> A stability vote may follow a successful preview release vote. This is
>> to vote the code base up to the next level of stability (to "beta",
>> then "rc", then "final"). This is also a lazy consensus vote.
>>
>> Once a release is final, a final release may be built and uploaded to
>> the Apache Nexus. A final release also includes additional non-Maven
>> artifacts containing the project's source code, and additional
>> artifacts containing JavaDoc or other reports.
>>
>> The final vote for a release is a binding vote, requiring at least 3
>> +1 votes and no vetoes, as outlined in
>> http://www.apache.org/foundation/voting.html
>>
>> Following a successful release vote, the final release artifacts in
>> the Apache Nexus repository may be released to the Maven Central
>> repository, and the additional artifacts moved into place for download
>> from the Apache distribution mirrors. This is also the point at which
>> the Tapestry wiki is updated to announce the new release (and provide
>> proper links to it), as well as announcements on the Tapestry user
>> mailing list and elsewhere.
>>
>> Bug fix releases are follow-ons to stable releases. Bug fix releases
>> automatically start at stability "rc", reflecting the fact that only
>> localized bug fixes are expected to be included in such a release.
>> Once all desired bug fixes are in place, a stability vote (to "final")
>> is followed by a release vote.
>>
>>
>> PROS:
>>
>> At-a-glance identification of version stability.
>> Alignment of Tapestry product releases ("5.3") with Tapestry version
>> numbers ("5.3", then "5.3.1").
>> Streamlined procedures for generating and distributing a preview release.
>> Simplification of issue tracking in JIRA.
>> Most votes can be lazy-consensus.
>>
>> CONS:
>>
>> People desiring early access must search the correct Nexus repository;
>> this will limit the exposure of preview releases.
>> More voting, as stability votes are separate from preview and final
>> release votes.
>
> As I said before, my understanding is that we can omit voting on preview packages since they are no
> releases in the sense of the ASF. A lazy consensus vote is nice though as it keeps the community
> involved.
>
That would be very nice ... so we vote on stability (lazy) and on the
final release (full), but any dev can create a preview at any time.
That will streamline a lot of things!
> Otherwise: +1
>
> Uli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] Proposal for New Versioning Procedures
Posted by Ulrich Stärk <ul...@spielviel.de>.
On 28.06.2011 18:22, Howard Lewis Ship wrote:
> Tapestry versioning structure as currently implemented in problematic
> for several reasons:
> 1. We vote and release non-final artifacts, which goes against the
> established model set by the board.
> 2. We have a proliferation of version numbers, which complicates the
> creation of builds, as well as tracking in JIRA.
> 3. Strictly numeric version numbers require a separate lookup in
> documentation to establish stability (alpha, beta, release candidate,
> final).
>
> The latter has been seen recently with people thinking that version
> 5.3.0 is a final build, rather than a very early alpha build.
>
> This proposal would simplify the version numbering scheme and link it
> properly to the release numbering scheme, while preserving efforts to
> ensure that final releases are available to a wide audience before
> being voted as final.
>
> Tapestry version numbers for stable releases will henseforth match
> Tapestry release numbers. A release number consists of a product
> number (5) and a index number (for example, 3) separated by a dot. At
> the time of this writing, the stable release number is "5.2" and the
> development release number is "5.3".
>
> A bug fix release replaces a stable release, adding an index number to
> the release number. Thus the first bug fix release of Tapestry 5.3
> will be Tapestry 5.3.1, followed by 5.3.2, etc. (as necessary).
>
> Only final, stable releases will be made widely available (via the
> Apache downloads page, or via the central Maven repository).
>
> Intermediate artifacts represent previews of the eventual stable
> release. The version number for such a preview is of the form
> "<release-number>-<stability>-<index>", where the release number is as
> described above, the stability is one of "alpha", "beta" or "rc", and
> the index number indicates the order within the stability. The index
> number starts at 1.
>
> "alpha" releases are not stable; the represent functionality in flux;
> classes and methods may be renamed or otherwise refactored between
> releases.
>
> "beta" releases occur once main functionality is complete; they exist
> to fix bug in old and new functionality, and fill and gaps in
> functionality.
>
> "rc" releases are "release candidates"; the functionality should be
> solid; the point of a release candidate is to get wide exposure to the
> new codebase to ensure that the final release is free of bugs.
>
> A preview release may be created at any time. A tag is created in
> Subversion to label the extact source from which the preview release
> is generated. The preview release is built and uploaded to the Apache
> Nexus. Once uploaded, the master version number should be advanced to
> the next index number within the same stability series (example:
> "5.3-alpha-2" to "5.3-alpha-3").
>
> Following a lazy-consensus vote, the URL for the preview release may
> be distributed on the Tapestry user mailing list. However, preview
> releases are deleted, not released. This is important ... preview
> releases are never released to the Maven Central repository, only
> final releases are distributed via Maven Central.
>
> A stability vote may follow a successful preview release vote. This is
> to vote the code base up to the next level of stability (to "beta",
> then "rc", then "final"). This is also a lazy consensus vote.
>
> Once a release is final, a final release may be built and uploaded to
> the Apache Nexus. A final release also includes additional non-Maven
> artifacts containing the project's source code, and additional
> artifacts containing JavaDoc or other reports.
>
> The final vote for a release is a binding vote, requiring at least 3
> +1 votes and no vetoes, as outlined in
> http://www.apache.org/foundation/voting.html
>
> Following a successful release vote, the final release artifacts in
> the Apache Nexus repository may be released to the Maven Central
> repository, and the additional artifacts moved into place for download
> from the Apache distribution mirrors. This is also the point at which
> the Tapestry wiki is updated to announce the new release (and provide
> proper links to it), as well as announcements on the Tapestry user
> mailing list and elsewhere.
>
> Bug fix releases are follow-ons to stable releases. Bug fix releases
> automatically start at stability "rc", reflecting the fact that only
> localized bug fixes are expected to be included in such a release.
> Once all desired bug fixes are in place, a stability vote (to "final")
> is followed by a release vote.
>
>
> PROS:
>
> At-a-glance identification of version stability.
> Alignment of Tapestry product releases ("5.3") with Tapestry version
> numbers ("5.3", then "5.3.1").
> Streamlined procedures for generating and distributing a preview release.
> Simplification of issue tracking in JIRA.
> Most votes can be lazy-consensus.
>
> CONS:
>
> People desiring early access must search the correct Nexus repository;
> this will limit the exposure of preview releases.
> More voting, as stability votes are separate from preview and final
> release votes.
As I said before, my understanding is that we can omit voting on preview packages since they are no
releases in the sense of the ASF. A lazy consensus vote is nice though as it keeps the community
involved.
Otherwise: +1
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] Proposal for New Versioning Procedures
Posted by Robert Zeigler <ro...@roxanemy.com>.
I was initially opposed to the "alpha, beta, final" naming, but after having a conversation with some tapestry developers yesterday who thought that 5.3.0 was a final/stable release (rather than an alpha, subject to, eg, api changes for new features, etc.) has convinced me otherwise.
+1
Robert
On Jun 28, 2011, at 6/2811:22 AM , Howard Lewis Ship wrote:
> Tapestry versioning structure as currently implemented in problematic
> for several reasons:
> 1. We vote and release non-final artifacts, which goes against the
> established model set by the board.
> 2. We have a proliferation of version numbers, which complicates the
> creation of builds, as well as tracking in JIRA.
> 3. Strictly numeric version numbers require a separate lookup in
> documentation to establish stability (alpha, beta, release candidate,
> final).
>
> The latter has been seen recently with people thinking that version
> 5.3.0 is a final build, rather than a very early alpha build.
>
> This proposal would simplify the version numbering scheme and link it
> properly to the release numbering scheme, while preserving efforts to
> ensure that final releases are available to a wide audience before
> being voted as final.
>
> Tapestry version numbers for stable releases will henseforth match
> Tapestry release numbers. A release number consists of a product
> number (5) and a index number (for example, 3) separated by a dot. At
> the time of this writing, the stable release number is "5.2" and the
> development release number is "5.3".
>
> A bug fix release replaces a stable release, adding an index number to
> the release number. Thus the first bug fix release of Tapestry 5.3
> will be Tapestry 5.3.1, followed by 5.3.2, etc. (as necessary).
>
> Only final, stable releases will be made widely available (via the
> Apache downloads page, or via the central Maven repository).
>
> Intermediate artifacts represent previews of the eventual stable
> release. The version number for such a preview is of the form
> "<release-number>-<stability>-<index>", where the release number is as
> described above, the stability is one of "alpha", "beta" or "rc", and
> the index number indicates the order within the stability. The index
> number starts at 1.
>
> "alpha" releases are not stable; the represent functionality in flux;
> classes and methods may be renamed or otherwise refactored between
> releases.
>
> "beta" releases occur once main functionality is complete; they exist
> to fix bug in old and new functionality, and fill and gaps in
> functionality.
>
> "rc" releases are "release candidates"; the functionality should be
> solid; the point of a release candidate is to get wide exposure to the
> new codebase to ensure that the final release is free of bugs.
>
> A preview release may be created at any time. A tag is created in
> Subversion to label the extact source from which the preview release
> is generated. The preview release is built and uploaded to the Apache
> Nexus. Once uploaded, the master version number should be advanced to
> the next index number within the same stability series (example:
> "5.3-alpha-2" to "5.3-alpha-3").
>
> Following a lazy-consensus vote, the URL for the preview release may
> be distributed on the Tapestry user mailing list. However, preview
> releases are deleted, not released. This is important ... preview
> releases are never released to the Maven Central repository, only
> final releases are distributed via Maven Central.
>
> A stability vote may follow a successful preview release vote. This is
> to vote the code base up to the next level of stability (to "beta",
> then "rc", then "final"). This is also a lazy consensus vote.
>
> Once a release is final, a final release may be built and uploaded to
> the Apache Nexus. A final release also includes additional non-Maven
> artifacts containing the project's source code, and additional
> artifacts containing JavaDoc or other reports.
>
> The final vote for a release is a binding vote, requiring at least 3
> +1 votes and no vetoes, as outlined in
> http://www.apache.org/foundation/voting.html
>
> Following a successful release vote, the final release artifacts in
> the Apache Nexus repository may be released to the Maven Central
> repository, and the additional artifacts moved into place for download
> from the Apache distribution mirrors. This is also the point at which
> the Tapestry wiki is updated to announce the new release (and provide
> proper links to it), as well as announcements on the Tapestry user
> mailing list and elsewhere.
>
> Bug fix releases are follow-ons to stable releases. Bug fix releases
> automatically start at stability "rc", reflecting the fact that only
> localized bug fixes are expected to be included in such a release.
> Once all desired bug fixes are in place, a stability vote (to "final")
> is followed by a release vote.
>
>
> PROS:
>
> At-a-glance identification of version stability.
> Alignment of Tapestry product releases ("5.3") with Tapestry version
> numbers ("5.3", then "5.3.1").
> Streamlined procedures for generating and distributing a preview release.
> Simplification of issue tracking in JIRA.
> Most votes can be lazy-consensus.
>
> CONS:
>
> People desiring early access must search the correct Nexus repository;
> this will limit the exposure of preview releases.
> More voting, as stability votes are separate from preview and final
> release votes.
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] Proposal for New Versioning Procedures
Posted by Howard Lewis Ship <hl...@gmail.com>.
As an addendum; under the new versioning scheme, @since and
@deprecated JavaDoc tags would refer to the Tapestry release ("5.3" or
"5.3.1") rather than the version ("5.3-alpha-2").
On Tue, Jun 28, 2011 at 9:22 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Tapestry versioning structure as currently implemented in problematic
> for several reasons:
> 1. We vote and release non-final artifacts, which goes against the
> established model set by the board.
> 2. We have a proliferation of version numbers, which complicates the
> creation of builds, as well as tracking in JIRA.
> 3. Strictly numeric version numbers require a separate lookup in
> documentation to establish stability (alpha, beta, release candidate,
> final).
>
> The latter has been seen recently with people thinking that version
> 5.3.0 is a final build, rather than a very early alpha build.
>
> This proposal would simplify the version numbering scheme and link it
> properly to the release numbering scheme, while preserving efforts to
> ensure that final releases are available to a wide audience before
> being voted as final.
>
> Tapestry version numbers for stable releases will henseforth match
> Tapestry release numbers. A release number consists of a product
> number (5) and a index number (for example, 3) separated by a dot. At
> the time of this writing, the stable release number is "5.2" and the
> development release number is "5.3".
>
> A bug fix release replaces a stable release, adding an index number to
> the release number. Thus the first bug fix release of Tapestry 5.3
> will be Tapestry 5.3.1, followed by 5.3.2, etc. (as necessary).
>
> Only final, stable releases will be made widely available (via the
> Apache downloads page, or via the central Maven repository).
>
> Intermediate artifacts represent previews of the eventual stable
> release. The version number for such a preview is of the form
> "<release-number>-<stability>-<index>", where the release number is as
> described above, the stability is one of "alpha", "beta" or "rc", and
> the index number indicates the order within the stability. The index
> number starts at 1.
>
> "alpha" releases are not stable; the represent functionality in flux;
> classes and methods may be renamed or otherwise refactored between
> releases.
>
> "beta" releases occur once main functionality is complete; they exist
> to fix bug in old and new functionality, and fill and gaps in
> functionality.
>
> "rc" releases are "release candidates"; the functionality should be
> solid; the point of a release candidate is to get wide exposure to the
> new codebase to ensure that the final release is free of bugs.
>
> A preview release may be created at any time. A tag is created in
> Subversion to label the extact source from which the preview release
> is generated. The preview release is built and uploaded to the Apache
> Nexus. Once uploaded, the master version number should be advanced to
> the next index number within the same stability series (example:
> "5.3-alpha-2" to "5.3-alpha-3").
>
> Following a lazy-consensus vote, the URL for the preview release may
> be distributed on the Tapestry user mailing list. However, preview
> releases are deleted, not released. This is important ... preview
> releases are never released to the Maven Central repository, only
> final releases are distributed via Maven Central.
>
> A stability vote may follow a successful preview release vote. This is
> to vote the code base up to the next level of stability (to "beta",
> then "rc", then "final"). This is also a lazy consensus vote.
>
> Once a release is final, a final release may be built and uploaded to
> the Apache Nexus. A final release also includes additional non-Maven
> artifacts containing the project's source code, and additional
> artifacts containing JavaDoc or other reports.
>
> The final vote for a release is a binding vote, requiring at least 3
> +1 votes and no vetoes, as outlined in
> http://www.apache.org/foundation/voting.html
>
> Following a successful release vote, the final release artifacts in
> the Apache Nexus repository may be released to the Maven Central
> repository, and the additional artifacts moved into place for download
> from the Apache distribution mirrors. This is also the point at which
> the Tapestry wiki is updated to announce the new release (and provide
> proper links to it), as well as announcements on the Tapestry user
> mailing list and elsewhere.
>
> Bug fix releases are follow-ons to stable releases. Bug fix releases
> automatically start at stability "rc", reflecting the fact that only
> localized bug fixes are expected to be included in such a release.
> Once all desired bug fixes are in place, a stability vote (to "final")
> is followed by a release vote.
>
>
> PROS:
>
> At-a-glance identification of version stability.
> Alignment of Tapestry product releases ("5.3") with Tapestry version
> numbers ("5.3", then "5.3.1").
> Streamlined procedures for generating and distributing a preview release.
> Simplification of issue tracking in JIRA.
> Most votes can be lazy-consensus.
>
> CONS:
>
> People desiring early access must search the correct Nexus repository;
> this will limit the exposure of preview releases.
> More voting, as stability votes are separate from preview and final
> release votes.
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] Proposal for New Versioning Procedures
Posted by Massimo Lusetti <ml...@gmail.com>.
On Tue, Jun 28, 2011 at 8:48 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> I fully understand Howard's reasoning but to me it comes down to
> whether you believe there is such a thing as a final release or not.
> Under the current, numbers-only release scheme, the micro version can
> be read as an indication of stability. Instinctively, it makes sense
> that micro release .0 is less stable than .9 for example. I'm worried
> that proposed, new version scheme will not have the desired effect,
> but alpha, beta,rc release will only make us release less frequently
> and each pre-release may not gain enough audience to meaningfully
> contribute to the stability of the release - in other words, what
> often happens, is that people will wait for whatever release is deemed
> "final" before coming to kick the tires. It could be argued that more
> frequent releases create more buzz (Jenkins, Jitsi as examples) since
> the *perceived* development velocity seems higher whereas less
> frequent stable releases are more desirable for existing users.
>
> It could increase users confidence in upgrading between micro versions
> if we simply guaranteed that micro versions are backwards compatible.
> I do understand Howard's concern with working on new code paths that
> are still in flux, since it's difficult to guarantee that interfaces
> for the code you are prototyping are not going change. If that leads
> to more frequent minor versions, so be it, it's not like we are going
> to run out of minor versions either. For a web framework, rather than
> an end-user product, it seems to me it's less compelling to produce a
> final release that has gone through several rounds of limited field
> testing.
>
> These are not necessarily the opposite proposals - especially if we
> are not voting on pre-releases/release previews, the actual numbered
> releases can keep the current numbering scheme as is, and previews is
> just an added step to evaluate a specific version in development (in
> other words, a mechanism to freeze a development version to share the
> same snapshot between all interested parties).
>
> A release in Apache terms is a source package on dist, any binaries
> are provided as a convenience only.
>
> Kalle
I completely agree with Kalle and I've already expressed my opinion
but if developers feels more comfortable it's a gain...
For the vote part I'm going with a -0
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] Proposal for New Versioning Procedures
Posted by Kalle Korhonen <ka...@gmail.com>.
I fully understand Howard's reasoning but to me it comes down to
whether you believe there is such a thing as a final release or not.
Under the current, numbers-only release scheme, the micro version can
be read as an indication of stability. Instinctively, it makes sense
that micro release .0 is less stable than .9 for example. I'm worried
that proposed, new version scheme will not have the desired effect,
but alpha, beta,rc release will only make us release less frequently
and each pre-release may not gain enough audience to meaningfully
contribute to the stability of the release - in other words, what
often happens, is that people will wait for whatever release is deemed
"final" before coming to kick the tires. It could be argued that more
frequent releases create more buzz (Jenkins, Jitsi as examples) since
the *perceived* development velocity seems higher whereas less
frequent stable releases are more desirable for existing users.
It could increase users confidence in upgrading between micro versions
if we simply guaranteed that micro versions are backwards compatible.
I do understand Howard's concern with working on new code paths that
are still in flux, since it's difficult to guarantee that interfaces
for the code you are prototyping are not going change. If that leads
to more frequent minor versions, so be it, it's not like we are going
to run out of minor versions either. For a web framework, rather than
an end-user product, it seems to me it's less compelling to produce a
final release that has gone through several rounds of limited field
testing.
These are not necessarily the opposite proposals - especially if we
are not voting on pre-releases/release previews, the actual numbered
releases can keep the current numbering scheme as is, and previews is
just an added step to evaluate a specific version in development (in
other words, a mechanism to freeze a development version to share the
same snapshot between all interested parties).
A release in Apache terms is a source package on dist, any binaries
are provided as a convenience only.
Kalle
On Tue, Jun 28, 2011 at 9:22 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Tapestry versioning structure as currently implemented in problematic
> for several reasons:
> 1. We vote and release non-final artifacts, which goes against the
> established model set by the board.
> 2. We have a proliferation of version numbers, which complicates the
> creation of builds, as well as tracking in JIRA.
> 3. Strictly numeric version numbers require a separate lookup in
> documentation to establish stability (alpha, beta, release candidate,
> final).
>
> The latter has been seen recently with people thinking that version
> 5.3.0 is a final build, rather than a very early alpha build.
>
> This proposal would simplify the version numbering scheme and link it
> properly to the release numbering scheme, while preserving efforts to
> ensure that final releases are available to a wide audience before
> being voted as final.
>
> Tapestry version numbers for stable releases will henseforth match
> Tapestry release numbers. A release number consists of a product
> number (5) and a index number (for example, 3) separated by a dot. At
> the time of this writing, the stable release number is "5.2" and the
> development release number is "5.3".
>
> A bug fix release replaces a stable release, adding an index number to
> the release number. Thus the first bug fix release of Tapestry 5.3
> will be Tapestry 5.3.1, followed by 5.3.2, etc. (as necessary).
>
> Only final, stable releases will be made widely available (via the
> Apache downloads page, or via the central Maven repository).
>
> Intermediate artifacts represent previews of the eventual stable
> release. The version number for such a preview is of the form
> "<release-number>-<stability>-<index>", where the release number is as
> described above, the stability is one of "alpha", "beta" or "rc", and
> the index number indicates the order within the stability. The index
> number starts at 1.
>
> "alpha" releases are not stable; the represent functionality in flux;
> classes and methods may be renamed or otherwise refactored between
> releases.
>
> "beta" releases occur once main functionality is complete; they exist
> to fix bug in old and new functionality, and fill and gaps in
> functionality.
>
> "rc" releases are "release candidates"; the functionality should be
> solid; the point of a release candidate is to get wide exposure to the
> new codebase to ensure that the final release is free of bugs.
>
> A preview release may be created at any time. A tag is created in
> Subversion to label the extact source from which the preview release
> is generated. The preview release is built and uploaded to the Apache
> Nexus. Once uploaded, the master version number should be advanced to
> the next index number within the same stability series (example:
> "5.3-alpha-2" to "5.3-alpha-3").
>
> Following a lazy-consensus vote, the URL for the preview release may
> be distributed on the Tapestry user mailing list. However, preview
> releases are deleted, not released. This is important ... preview
> releases are never released to the Maven Central repository, only
> final releases are distributed via Maven Central.
>
> A stability vote may follow a successful preview release vote. This is
> to vote the code base up to the next level of stability (to "beta",
> then "rc", then "final"). This is also a lazy consensus vote.
>
> Once a release is final, a final release may be built and uploaded to
> the Apache Nexus. A final release also includes additional non-Maven
> artifacts containing the project's source code, and additional
> artifacts containing JavaDoc or other reports.
>
> The final vote for a release is a binding vote, requiring at least 3
> +1 votes and no vetoes, as outlined in
> http://www.apache.org/foundation/voting.html
>
> Following a successful release vote, the final release artifacts in
> the Apache Nexus repository may be released to the Maven Central
> repository, and the additional artifacts moved into place for download
> from the Apache distribution mirrors. This is also the point at which
> the Tapestry wiki is updated to announce the new release (and provide
> proper links to it), as well as announcements on the Tapestry user
> mailing list and elsewhere.
>
> Bug fix releases are follow-ons to stable releases. Bug fix releases
> automatically start at stability "rc", reflecting the fact that only
> localized bug fixes are expected to be included in such a release.
> Once all desired bug fixes are in place, a stability vote (to "final")
> is followed by a release vote.
>
>
> PROS:
>
> At-a-glance identification of version stability.
> Alignment of Tapestry product releases ("5.3") with Tapestry version
> numbers ("5.3", then "5.3.1").
> Streamlined procedures for generating and distributing a preview release.
> Simplification of issue tracking in JIRA.
> Most votes can be lazy-consensus.
>
> CONS:
>
> People desiring early access must search the correct Nexus repository;
> this will limit the exposure of preview releases.
> More voting, as stability votes are separate from preview and final
> release votes.
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] Proposal for New Versioning Procedures
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 28 Jun 2011 14:25:34 -0300, Howard Lewis Ship <hl...@gmail.com>
wrote:
> As I'm interpreting it, the "previews" are not releases as they are
> not distributed via the Apache Mirrors or Maven Central, and will take
> a small amount of work to access (updating the list of Maven
> repositories in the build script).
Thanks for the clarification. :)
> So the process is that a developer will generate the preview
> artifacts, and deal with committing the version number changes and
> create a tag. Then a vote starts. At the end of the vote, a message
> can go out on the user mailing list along the lines of:
I don't think we'll have more votes than we already do, as all artifacts,
releases or not, have been having a version number and votes.
> Previewing a release is a great way to help us ensure the stability of
> the final release, and learn about any upgrade problems early enough
> to address them. It's a great way to contribute back to the Tapestry
> community!
Agreed. :) I don't think the need to add a Maven repository for using
alpha and beta versions will be a problem for early adopters. They're
already the more knowledgeable, experimenting users.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] Proposal for New Versioning Procedures
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
+1.
Just one question: as per Apache guidelines, do non-stable releases need a
vote to be released?
On Tue, 28 Jun 2011 13:22:05 -0300, Howard Lewis Ship <hl...@gmail.com>
wrote:
> Tapestry versioning structure as currently implemented in problematic
> for several reasons:
> 1. We vote and release non-final artifacts, which goes against the
> established model set by the board.
> 2. We have a proliferation of version numbers, which complicates the
> creation of builds, as well as tracking in JIRA.
> 3. Strictly numeric version numbers require a separate lookup in
> documentation to establish stability (alpha, beta, release candidate,
> final).
>
> The latter has been seen recently with people thinking that version
> 5.3.0 is a final build, rather than a very early alpha build.
>
> This proposal would simplify the version numbering scheme and link it
> properly to the release numbering scheme, while preserving efforts to
> ensure that final releases are available to a wide audience before
> being voted as final.
>
> Tapestry version numbers for stable releases will henseforth match
> Tapestry release numbers. A release number consists of a product
> number (5) and a index number (for example, 3) separated by a dot. At
> the time of this writing, the stable release number is "5.2" and the
> development release number is "5.3".
>
> A bug fix release replaces a stable release, adding an index number to
> the release number. Thus the first bug fix release of Tapestry 5.3
> will be Tapestry 5.3.1, followed by 5.3.2, etc. (as necessary).
>
> Only final, stable releases will be made widely available (via the
> Apache downloads page, or via the central Maven repository).
>
> Intermediate artifacts represent previews of the eventual stable
> release. The version number for such a preview is of the form
> "<release-number>-<stability>-<index>", where the release number is as
> described above, the stability is one of "alpha", "beta" or "rc", and
> the index number indicates the order within the stability. The index
> number starts at 1.
>
> "alpha" releases are not stable; the represent functionality in flux;
> classes and methods may be renamed or otherwise refactored between
> releases.
>
> "beta" releases occur once main functionality is complete; they exist
> to fix bug in old and new functionality, and fill and gaps in
> functionality.
>
> "rc" releases are "release candidates"; the functionality should be
> solid; the point of a release candidate is to get wide exposure to the
> new codebase to ensure that the final release is free of bugs.
>
> A preview release may be created at any time. A tag is created in
> Subversion to label the extact source from which the preview release
> is generated. The preview release is built and uploaded to the Apache
> Nexus. Once uploaded, the master version number should be advanced to
> the next index number within the same stability series (example:
> "5.3-alpha-2" to "5.3-alpha-3").
>
> Following a lazy-consensus vote, the URL for the preview release may
> be distributed on the Tapestry user mailing list. However, preview
> releases are deleted, not released. This is important ... preview
> releases are never released to the Maven Central repository, only
> final releases are distributed via Maven Central.
>
> A stability vote may follow a successful preview release vote. This is
> to vote the code base up to the next level of stability (to "beta",
> then "rc", then "final"). This is also a lazy consensus vote.
>
> Once a release is final, a final release may be built and uploaded to
> the Apache Nexus. A final release also includes additional non-Maven
> artifacts containing the project's source code, and additional
> artifacts containing JavaDoc or other reports.
>
> The final vote for a release is a binding vote, requiring at least 3
> +1 votes and no vetoes, as outlined in
> http://www.apache.org/foundation/voting.html
>
> Following a successful release vote, the final release artifacts in
> the Apache Nexus repository may be released to the Maven Central
> repository, and the additional artifacts moved into place for download
> from the Apache distribution mirrors. This is also the point at which
> the Tapestry wiki is updated to announce the new release (and provide
> proper links to it), as well as announcements on the Tapestry user
> mailing list and elsewhere.
>
> Bug fix releases are follow-ons to stable releases. Bug fix releases
> automatically start at stability "rc", reflecting the fact that only
> localized bug fixes are expected to be included in such a release.
> Once all desired bug fixes are in place, a stability vote (to "final")
> is followed by a release vote.
>
>
> PROS:
>
> At-a-glance identification of version stability.
> Alignment of Tapestry product releases ("5.3") with Tapestry version
> numbers ("5.3", then "5.3.1").
> Streamlined procedures for generating and distributing a preview release.
> Simplification of issue tracking in JIRA.
> Most votes can be lazy-consensus.
>
> CONS:
>
> People desiring early access must search the correct Nexus repository;
> this will limit the exposure of preview releases.
> More voting, as stability votes are separate from preview and final
> release votes.
>
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org