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/23 01:46:04 UTC
A question of vocabulary: release vs. version vs. ???
I've been noticing that "release" is a bit overload.
We have a product, "Tapestry" or "Apache Tapestry", or "Tapestry 5".
We have versions, such a 5.2.6 or 5.3.0.
We have releases such as 5.2 or 5.3.
However, something seems odd in the phrase "We are pleased to announce
the release of Tapestry 5.2.6, the new stable version of Tapestry
5.2.". Actually, that reads well. But I keep having problems
elsewhere with the verb "release" vs. the noun "release" (as a
sequence of versions). Is it confusing anyone else? Is there a
better set of terms we should stick with?
--
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: A question of vocabulary: release vs. version vs. ???
Posted by Kalle Korhonen <ka...@gmail.com>.
Release is a release, especially given that it's all in the open -
i.e. there's no hidden internal process to produce release candidates
to a subset of users leading to a GA release. Re-wording your sentence
to:
"We are pleased to announce a maintenance release of Apache Tapestry
5, version 5.2.6." You could continue with "... for the stable T5.2
line" but seems unnecessary to me since the version number already
indicates the product line it's for. Perhaps I'm advocating the use of
"product line" as a more consumer-friendly term for a branch in cases
where using a release (the noun) would be too confusing.
I think Apache branding guidelines in fairly strict terms require
using "Apache This" or "Apache That" when speaking about Apache
projects and products.
Kalle
On Wed, Jun 22, 2011 at 4:46 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I've been noticing that "release" is a bit overload.
>
> We have a product, "Tapestry" or "Apache Tapestry", or "Tapestry 5".
>
> We have versions, such a 5.2.6 or 5.3.0.
>
> We have releases such as 5.2 or 5.3.
>
> However, something seems odd in the phrase "We are pleased to announce
> the release of Tapestry 5.2.6, the new stable version of Tapestry
> 5.2.". Actually, that reads well. But I keep having problems
> elsewhere with the verb "release" vs. the noun "release" (as a
> sequence of versions). Is it confusing anyone else? Is there a
> better set of terms we should stick with?
>
> --
> 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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Massimo Lusetti <ml...@gmail.com>.
On Fri, Jun 24, 2011 at 9:26 PM, Robert Zeigler
<ro...@roxanemy.com> wrote:
> I'm content with calling it 5.3.0. It's the first release on the 5.3 code base. Even calling something "final" is kinda weird, imo. Like, 5.2.5 was "final"...except we released 5.2.6... The only way to declare something final is retrospectively: look, we didn't make any more 5.0 releases; I guess 5.0.19 was final... at least for now.
>
> As for "alpha"... I think 5.3.0-SNAPSHOT fulfills that role, personally. Now we have 5.3.1-SNAPSHOT; those builds are the "alpha" builds of the 5.3.1 release.
Clear, concise and fair.
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] new release process (WAS: Re: A question of vocabulary: release vs. version vs. ???)
Posted by Robert Zeigler <ro...@roxanemy.com>.
I'm content with calling it 5.3.0. It's the first release on the 5.3 code base. Even calling something "final" is kinda weird, imo. Like, 5.2.5 was "final"...except we released 5.2.6... The only way to declare something final is retrospectively: look, we didn't make any more 5.0 releases; I guess 5.0.19 was final... at least for now.
As for "alpha"... I think 5.3.0-SNAPSHOT fulfills that role, personally. Now we have 5.3.1-SNAPSHOT; those builds are the "alpha" builds of the 5.3.1 release.
Robert
On Jun 24, 2011, at 6/242:20 PM , Thiago H. de Paula Figueiredo wrote:
> Hi, Kalle!
>
> I wasn't clear with my words: I don't think 5.3.0 isn't production-ready now. I haven't even used it yet :'(, so I can't say anything bad about it. I meant 5.3.0 is not final.
>
> 5.3.0, now, is an alpha release, so I think the version and JAR names should have some suffix about it somehow. The JBoss conventions, for example, are these (http://community.jboss.org/wiki/JBossProjectVersioning):
>
> major.minor.micro.Alpha[n]
> major.minor.micro.Beta[n]
> major.minor.micro.CR[n]
> major.minor.micro.Final
>
> I don't like suffixes for final versions nor the use of uppercase letters nor I think Tapestry needs 4 release stages (just alpha or beta and final, besides snapshots, should be enough), but I guess we could adapt it.
>
> --
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Kalle Korhonen <ka...@gmail.com>.
On Fri, Jun 24, 2011 at 6:11 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I think we're coming to a collision in basic goals; I really want to
> focus on a way to maximize exposure of Tapestry betas and RCs prior to
> a final release, to help ensure that the final release really is
> final.
Agreed. Clearly there are different approaches here which both are
proven to work (e.g. JBoss vs. OpenBSD releases) with each their pros
and cons. But like Robert, I just don't think there's such a thing for
a framework as a final release and that's the crux of where our
viewpoints differ. And even if there was, what difference would it
make if 5.3.final+1 would be backwards compatible? But enough said,
probably best to go forward with a vote if you want a consensus
opinion.
> its easy enough for people to temporarily accesss such a repository.
> It could just be a matter of staging to the Apache Nexus and closing,
> but not ever releasing, the repository.
The good thing about the staging repos is that you can just drop them
once you are done without ever having to release the bits to the wild
(i.e. central in Maven's case).
Kalle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 27 Jun 2011 18:33:18 -0300, Massimo Lusetti <ml...@gmail.com>
wrote:
> So I'll see on jira that my issue has been resolved for version 5.3
> and I got 5.3-alpha2, 5.3-beta1, 5.3-beta2, 5.3-RC1 from which to
> choose... Which one should I choose?
The latest one. :) Issues would be solved for 5.3-alpha, for example.
My suggestion is to have a single suffix (alpha), at most two (alpha and
beta).
> I suppose the majority of people
> will go for the latest which should be 5.3-RC1, so tell me where this
> is all different from having 5.3.1, 5.3.2, 5.3.4, 5.3.5 and so on?
With the suffixes, people know when a release is final or not, and today
it seem at least some don't. Check this thread:
http://tapestry.1045711.n5.nabble.com/ANNOUNCE-Tapestry-5-3-0-td4522183.html
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Massimo Lusetti <ml...@gmail.com>.
On Tue, Jun 28, 2011 at 3:05 AM, Martin Strand
<do...@gmail.com> wrote:
> I agree, the current scheme makes sense.
> Furthermore, the website makes it pretty clear which version is the stable
> one:
> http://tapestry.apache.org/download.html
Just to clarify that mine is not a strong position against this
changes, I think it's better the current one but I can live with the
new one if chosen. My fear is that in the long term it will make more
confusion then what have now...
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Martin Strand <do...@gmail.com>.
I agree, the current scheme makes sense.
Furthermore, the website makes it pretty clear which version is the stable
one:
http://tapestry.apache.org/download.html
On Tue, 28 Jun 2011 00:28:44 +0200, Chris Poulsen <ma...@nesluop.dk>
wrote:
> I like the current release scheme. Its similar to that of tomcat isn't
> it? -
> I've never had trouble picking the right version of tomcat, their "which
> version" page does a really good job of pointing you in the right
> direction,
> and letting you know if something isn't considered production-ready etc..
> Perhaps tapestry just needs a description page like the one tomcat has?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Chris Poulsen <ma...@nesluop.dk>.
I like the current release scheme. Its similar to that of tomcat isn't it? -
I've never had trouble picking the right version of tomcat, their "which
version" page does a really good job of pointing you in the right direction,
and letting you know if something isn't considered production-ready etc..
Perhaps tapestry just needs a description page like the one tomcat has?
--
Chris
On Tue, Jun 28, 2011 at 12:00 AM, Massimo Lusetti <ml...@gmail.com>wrote:
> On Mon, Jun 27, 2011 at 11:40 PM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
> > You might be down to comparing fix dates against release dates as you
> > update your POM/build.gradle to point at the temporary Nexus
> > repository containing the pre-release artifacts.
> >
> > In other words, we're raining the bar on people wanting to use
> > pre-release artifacts (today's alphas and betas) to make things much
> > simpler for the 99% that just want to upgrade from a final release to
> > a final release.
> >
> > Further, in terms of finding bug fixes, the release notes will be
> > simpler (if longer), so they won't have to search through lots of
> > different listings of fixed bugs ("in alpha 1", "in beta 5"). They'll
> > be a single long list of bugs fixed in 5.3 (i.e., all bugs fixed since
> > the previous stable release, 5.2).
> >
> > Again, this is simpler in every way except for the few people who wish
> > to try out pre-release builds.
>
> Again I don't see it that way and I'm sure I'm missing something obvious.
>
> I think not having the releases (be there alpha beta gamma or omega)
> out in the wild but only in the "restrict" circle of the people
> wanting to try it out is something that reduce it's visibility and the
> opportunity for bugs to came out.
>
> This will reflect on the quality of "released code" (mean there what
> you want). This will increase the time between each releases.
>
> If you clearly state on which is the target for a particular release
> cycle then you could declare a release as final otherwise is difficult
> to do it, isn't it? And even doing it is still difficult due the the
> "last minute bug" coming out...
>
> Doing a good release process is very difficult and cannot be
> simplified by a name, the current scheme works pretty well even with
> the current 5.3 trunk which has gone thought pretty deep inner
> changes...
>
> Just my 2 cents
> --
> Massimo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: [DISCUSS] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Massimo Lusetti <ml...@gmail.com>.
On Mon, Jun 27, 2011 at 11:40 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> You might be down to comparing fix dates against release dates as you
> update your POM/build.gradle to point at the temporary Nexus
> repository containing the pre-release artifacts.
>
> In other words, we're raining the bar on people wanting to use
> pre-release artifacts (today's alphas and betas) to make things much
> simpler for the 99% that just want to upgrade from a final release to
> a final release.
>
> Further, in terms of finding bug fixes, the release notes will be
> simpler (if longer), so they won't have to search through lots of
> different listings of fixed bugs ("in alpha 1", "in beta 5"). They'll
> be a single long list of bugs fixed in 5.3 (i.e., all bugs fixed since
> the previous stable release, 5.2).
>
> Again, this is simpler in every way except for the few people who wish
> to try out pre-release builds.
Again I don't see it that way and I'm sure I'm missing something obvious.
I think not having the releases (be there alpha beta gamma or omega)
out in the wild but only in the "restrict" circle of the people
wanting to try it out is something that reduce it's visibility and the
opportunity for bugs to came out.
This will reflect on the quality of "released code" (mean there what
you want). This will increase the time between each releases.
If you clearly state on which is the target for a particular release
cycle then you could declare a release as final otherwise is difficult
to do it, isn't it? And even doing it is still difficult due the the
"last minute bug" coming out...
Doing a good release process is very difficult and cannot be
simplified by a name, the current scheme works pretty well even with
the current 5.3 trunk which has gone thought pretty deep inner
changes...
Just my 2 cents
--
Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Mon, Jun 27, 2011 at 2:33 PM, Massimo Lusetti <ml...@gmail.com> wrote:
> On Mon, Jun 27, 2011 at 11:14 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>> I think if we can swallow one part of this ... that pre-final-release
>> artifacts are available only via a temporary Nexus repository, then
>> it's actually simpler.
>>
>> Bugs are tracked against a single version number ("5.3") not a series
>> ("5.3.0", "5.3.1", etc.).
>>
>> The artifacts available for download or via Maven are fewer and more
>> sensible, and its more clear about stability ("5.3-alpha-2" is clearly
>> not a final release).
>
> So I'll see on jira that my issue has been resolved for version 5.3
> and I got 5.3-alpha2, 5.3-beta1, 5.3-beta2, 5.3-RC1 from which to
> choose... Which one should I choose? I suppose the majority of people
> will go for the latest which should be 5.3-RC1, so tell me where this
> is all different from having 5.3.1, 5.3.2, 5.3.4, 5.3.5 and so on?
> Despite the fact that with 5.3.x in jira I exactly know from which
> version on my fix is included...
>
> I still think it's simply too much for a versioning scheme.
You might be down to comparing fix dates against release dates as you
update your POM/build.gradle to point at the temporary Nexus
repository containing the pre-release artifacts.
In other words, we're raining the bar on people wanting to use
pre-release artifacts (today's alphas and betas) to make things much
simpler for the 99% that just want to upgrade from a final release to
a final release.
Further, in terms of finding bug fixes, the release notes will be
simpler (if longer), so they won't have to search through lots of
different listings of fixed bugs ("in alpha 1", "in beta 5"). They'll
be a single long list of bugs fixed in 5.3 (i.e., all bugs fixed since
the previous stable release, 5.2).
Again, this is simpler in every way except for the few people who wish
to try out pre-release builds.
>
> 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
>
>
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Massimo Lusetti <ml...@gmail.com>.
On Mon, Jun 27, 2011 at 11:14 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I think if we can swallow one part of this ... that pre-final-release
> artifacts are available only via a temporary Nexus repository, then
> it's actually simpler.
>
> Bugs are tracked against a single version number ("5.3") not a series
> ("5.3.0", "5.3.1", etc.).
>
> The artifacts available for download or via Maven are fewer and more
> sensible, and its more clear about stability ("5.3-alpha-2" is clearly
> not a final release).
So I'll see on jira that my issue has been resolved for version 5.3
and I got 5.3-alpha2, 5.3-beta1, 5.3-beta2, 5.3-RC1 from which to
choose... Which one should I choose? I suppose the majority of people
will go for the latest which should be 5.3-RC1, so tell me where this
is all different from having 5.3.1, 5.3.2, 5.3.4, 5.3.5 and so on?
Despite the fact that with 5.3.x in jira I exactly know from which
version on my fix is included...
I still think it's simply too much for a versioning scheme.
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 27 Jun 2011 18:14:05 -0300, Howard Lewis Ship <hl...@gmail.com>
wrote:
> The artifacts available for download or via Maven are fewer and more
> sensible, and its more clear about stability ("5.3-alpha-2" is clearly
> not a final release).
+100 to that.
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Mon, Jun 27, 2011 at 2:08 PM, Massimo Lusetti <ml...@gmail.com> wrote:
> On Mon, Jun 27, 2011 at 8:42 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>> I suspect there won't be a problem as long as the linkage is to final
>> version numbers ("5.3") and not pre-release version numbers
>> ("5.3-beta-2").
>
> I find this all too over engineered, it complicates more then it simplify.
I think if we can swallow one part of this ... that pre-final-release
artifacts are available only via a temporary Nexus repository, then
it's actually simpler.
Bugs are tracked against a single version number ("5.3") not a series
("5.3.0", "5.3.1", etc.).
The artifacts available for download or via Maven are fewer and more
sensible, and its more clear about stability ("5.3-alpha-2" is clearly
not a final release).
>
> 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
>
>
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 27 Jun 2011 18:08:03 -0300, Massimo Lusetti <ml...@gmail.com>
wrote:
> On Mon, Jun 27, 2011 at 8:42 PM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
>> I suspect there won't be a problem as long as the linkage is to final
>> version numbers ("5.3") and not pre-release version numbers
>> ("5.3-beta-2").
>
> I find this all too over engineered, it complicates more then it
> simplify.
I disagree. We just had one person in the users mailing list asking if
5.3.0 was an alpha, beta or final version.
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Massimo Lusetti <ml...@gmail.com>.
On Mon, Jun 27, 2011 at 8:42 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I suspect there won't be a problem as long as the linkage is to final
> version numbers ("5.3") and not pre-release version numbers
> ("5.3-beta-2").
I find this all too over engineered, it complicates more then it simplify.
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Mon, Jun 27, 2011 at 11:19 AM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Sun, Jun 26, 2011 at 8:33 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> Someone brought up compatibility for the release numbering with how
>> Maven sequences version numbers. Does anyone have some insight into
>> where that would make a difference?
>
> Yes I brought it up, but I don't think it's an insurmountable issue,
> just that it won't work as well. I believe the major issue is with
> version ranges, which likely is a problem mainly for third-party
> add-ons (e.g. your lib requires 5.3 or above). Nearest version
> resolution however takes care of user usually getting the desired
> library versions as dependencies (if he sets them as explicit
> dependencies). See
> http://mojo.codehaus.org/versions-maven-plugin/version-rules.html for
> more info (it's for a plugin but well documents Maven's core version
> resolution - not that Maven 2.x and 3.x differ in that respect).
>
I suspect there won't be a problem as long as the linkage is to final
version numbers ("5.3") and not pre-release version numbers
("5.3-beta-2").
> Kalle
>
>
>>
>> On Sat, Jun 25, 2011 at 9:29 AM, Thiago H. de Paula Figueiredo
>> <th...@gmail.com> wrote:
>>> On Fri, 24 Jun 2011 22:11:25 -0300, Howard Lewis Ship <hl...@gmail.com>
>>> wrote:
>>>
>>>> I think we're coming to a collision in basic goals; I really want to
>>>> focus on a way to maximize exposure of Tapestry betas and RCs prior to
>>>> a final release, to help ensure that the final release really is
>>>> final.
>>>>
>>>> A secondary goal here is to make it easier for people to "read" the
>>>> version number and know the stability without referencing other
>>>> sources; Will 5.3.7 be an alpha release, a beta release, or a release
>>>> candidate? What about 5.3-rc-2?
>>>
>>> That's exactly what I was trying to say. ;)
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> 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
>
>
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Kalle Korhonen <ka...@gmail.com>.
On Sun, Jun 26, 2011 at 8:33 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Someone brought up compatibility for the release numbering with how
> Maven sequences version numbers. Does anyone have some insight into
> where that would make a difference?
Yes I brought it up, but I don't think it's an insurmountable issue,
just that it won't work as well. I believe the major issue is with
version ranges, which likely is a problem mainly for third-party
add-ons (e.g. your lib requires 5.3 or above). Nearest version
resolution however takes care of user usually getting the desired
library versions as dependencies (if he sets them as explicit
dependencies). See
http://mojo.codehaus.org/versions-maven-plugin/version-rules.html for
more info (it's for a plugin but well documents Maven's core version
resolution - not that Maven 2.x and 3.x differ in that respect).
Kalle
>
> On Sat, Jun 25, 2011 at 9:29 AM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>> On Fri, 24 Jun 2011 22:11:25 -0300, Howard Lewis Ship <hl...@gmail.com>
>> wrote:
>>
>>> I think we're coming to a collision in basic goals; I really want to
>>> focus on a way to maximize exposure of Tapestry betas and RCs prior to
>>> a final release, to help ensure that the final release really is
>>> final.
>>>
>>> A secondary goal here is to make it easier for people to "read" the
>>> version number and know the stability without referencing other
>>> sources; Will 5.3.7 be an alpha release, a beta release, or a release
>>> candidate? What about 5.3-rc-2?
>>
>> That's exactly what I was trying to say. ;)
>>
>> --
>> 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
>>
>
>
>
> --
> 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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Howard Lewis Ship <hl...@gmail.com>.
Someone brought up compatibility for the release numbering with how
Maven sequences version numbers. Does anyone have some insight into
where that would make a difference?
On Sat, Jun 25, 2011 at 9:29 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Fri, 24 Jun 2011 22:11:25 -0300, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
>> I think we're coming to a collision in basic goals; I really want to
>> focus on a way to maximize exposure of Tapestry betas and RCs prior to
>> a final release, to help ensure that the final release really is
>> final.
>>
>> A secondary goal here is to make it easier for people to "read" the
>> version number and know the stability without referencing other
>> sources; Will 5.3.7 be an alpha release, a beta release, or a release
>> candidate? What about 5.3-rc-2?
>
> That's exactly what I was trying to say. ;)
>
> --
> 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
>
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, 24 Jun 2011 22:11:25 -0300, Howard Lewis Ship <hl...@gmail.com>
wrote:
> I think we're coming to a collision in basic goals; I really want to
> focus on a way to maximize exposure of Tapestry betas and RCs prior to
> a final release, to help ensure that the final release really is
> final.
>
> A secondary goal here is to make it easier for people to "read" the
> version number and know the stability without referencing other
> sources; Will 5.3.7 be an alpha release, a beta release, or a release
> candidate? What about 5.3-rc-2?
That's exactly what I was trying to say. ;)
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Fri, Jun 24, 2011 at 5:21 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Fri, Jun 24, 2011 at 4:57 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> So my proposal:
>> Tapestry release version numbers consist of three numbers and an
>> optional suffix.
>> Thus a complete version number might be "5.3-alpha-2".
>> final releases have no suffix, thus "5.3" will be the final version
>> number for the Tapestry 5.3 major release
>> How does that sound? It also means that our next version number will
>> be "5.3-alpha-2" ... and perhaps we should consolidate our JIRA
>> version numbers.
>
> First of all, it's easy to freeze -SNAPSHOT - I publish frozen
> snapshots (i.e. version x.x-mycompany-1) all the time to company's
> internal Maven repo just so that I can take advantage of auto-built
> snapshots but at the same not block releasing our own products.
>
> Anyway, I just don't think you are thinking through the full
> implications of this (but it could be me as well who isn't :). The
> version resolution will not work as well with alpha, beta etc.
> suffixes and I can just see lots of third party library developers
> releasing against alpha versions which may just add to the confusion.
> If the concern is with stability and we want to limit the audience,
> let me suggest an alternative: numeric versions only but alphas and
> release candidates are only available through staging repo (which can
> be longer lived than what we now typically use) and we advertise the
> repo url to a bigger audience (on the user list). For suffix proposal,
> I'm prepared to cast my -1 for reasons I've stated in this thread (but
> as non-binding, feel free to ignore).
>
I think we're coming to a collision in basic goals; I really want to
focus on a way to maximize exposure of Tapestry betas and RCs prior to
a final release, to help ensure that the final release really is
final.
A secondary goal here is to make it easier for people to "read" the
version number and know the stability without referencing other
sources; Will 5.3.7 be an alpha release, a beta release, or a release
candidate? What about 5.3-rc-2?
This is really two different discussions: how we release non-final
versions, and how we number and label them.
I think the Apache Powers-That-Be might like a secondary repository
used for less-than-final releases, and certainly with Maven/Gradle/Ivy
its easy enough for people to temporarily accesss such a repository.
It could just be a matter of staging to the Apache Nexus and closing,
but not ever releasing, the repository.
> Kalle
>
> ---------------------------------------------------------------------
> 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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Kalle Korhonen <ka...@gmail.com>.
On Fri, Jun 24, 2011 at 4:57 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> So my proposal:
> Tapestry release version numbers consist of three numbers and an
> optional suffix.
> Thus a complete version number might be "5.3-alpha-2".
> final releases have no suffix, thus "5.3" will be the final version
> number for the Tapestry 5.3 major release
> How does that sound? It also means that our next version number will
> be "5.3-alpha-2" ... and perhaps we should consolidate our JIRA
> version numbers.
First of all, it's easy to freeze -SNAPSHOT - I publish frozen
snapshots (i.e. version x.x-mycompany-1) all the time to company's
internal Maven repo just so that I can take advantage of auto-built
snapshots but at the same not block releasing our own products.
Anyway, I just don't think you are thinking through the full
implications of this (but it could be me as well who isn't :). The
version resolution will not work as well with alpha, beta etc.
suffixes and I can just see lots of third party library developers
releasing against alpha versions which may just add to the confusion.
If the concern is with stability and we want to limit the audience,
let me suggest an alternative: numeric versions only but alphas and
release candidates are only available through staging repo (which can
be longer lived than what we now typically use) and we advertise the
repo url to a bigger audience (on the user list). For suffix proposal,
I'm prepared to cast my -1 for reasons I've stated in this thread (but
as non-binding, feel free to ignore).
Kalle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Fri, Jun 24, 2011 at 2:56 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Fri, 24 Jun 2011 18:43:17 -0300, Massimo Lusetti <ml...@gmail.com>
> wrote:
>
>> OpenBSD is an open source operating system project and is by far a lot
>> more complicated then a web framework.
>> It has a streamlined release process which results in a series of
>> successful releases, plus the OpenBSD's snapshots are by far a lot
>> more stable then a lot of other operating system "stable releases", I
>> see Tapestry release and snapshots story very similar (especially in
>> term of stability)
>
> So I think we don't need to call 5.3.0 an alpha release. :) As you
> suggested, let's consider snapshots as our alpha releases.
I think we are colliding on terminology here.
Motivated types can download the source and build it.
However, users using Maven, Gradle or Ivy will benefit greatly from
having a pre-compiled release in a repository, preferably Maven
Central. Further, it would be good if that version number did not
include the suffix "-SNAPSHOT".
That brings us full-circle to where we started.
It seems like the best way to resolve this is to modify what we've
been doing, and add a new step.
Instead of a simple suffix, we can incorporate a stability
designation. Thus "5.3-alpha-1" instead of "5.3.0".
Once a release is voted up in stability (that is, voted from "alpha"
to "beta", "beta" to "rc" or "rc" to "final"), the FOLLOWING release
gets the new stability, with the assumption that no changes between
the vote and the release cause instability. In other words, when we
vote "5.3-beta-2" as a release candidate, then the NEXT release will
be "5.3-rc-1" ... and its bits should be as close as possible to
5.3-beta-2 ... and ideally, the only difference should be the version
number.
Final releases will have no suffix, i.e, we might vote "5.3-rc-2" as
final, and then release "5.3".
TBD: Process and naming conventions for bug fix releases. Should the
first bug fix release on top of 5.3 be called "5.3.1"? "5.3-fix-1"?
Do we release it then vote on stability?
I'm leaning towards creating and voting on a "5.3.1-rc-1" containing
the fix, then voting that as stable to release "5.3.1".
Note that does represent a large change, and I think a large
improvement, to how the third digit in the version number is
interpreted.
We may also want to reconsider how bugs are assigned to JIRA versions.
I would think that, perhaps, we should have a JIRA version for each
final release; so just a 5.3 and a 5.4. We would also create a JIRA
version for each bugfix release, such as 5.3.1. The same approach
should apply to our @since tags.
So my proposal:
Tapestry release version numbers consist of three numbers and an
optional suffix.
The first number is "5", the product number (thus Tapestry 4 was a
different product). Let this never be "6"!
The second number is the major release. Currently this would be "3".
The third number is the bugfix release number. This is currently not
present, as Tapestry 5.3 has not had a final release yet.
The suffix indicates stability and includes a sequence number within
the stability. The stability term is "alpha", "beta" or "rc" in
ascending stability. The suffix concludes with a dash and a sequence
number, such as "alpha-2", or "beta-3". The suffix, when present, is
separated from the release number by a dash.
alpha releases are known to be incomplete and in-flux
beta releases represent stability of features, with an emphasis on
fixing bugs in new and existing code
rc (release candidate) releases represent the most stable code, with
only the most serious bugs being fixed
Thus a complete version number might be "5.3-alpha-2".
final releases have no suffix, thus "5.3" will be the final version
number for the Tapestry 5.3 major release
After a release has been made available for a reasonable period (up to
several weeks for a release candidate), a stability vote may be run. A
successful stability vote will spur the creation of a new release with
the next level of stability. Example: a successful stability vote on
"5.3-beta-2" will allow the next release to be "5.3-rc-1".
An unsuccesful stability vote should result in a work towards a new
release at the same stability. Thus, if the stability vote for
"5.3-beta-2" fails, there should be follow-on work to create a
"5.3-beta-3" release, then a vote on that.
Bug fix releases follow an abbreviated stability schedule, starting
automatically at "rc" (release candidate) status.
How does that sound? It also means that our next version number will
be "5.3-alpha-2" ... and perhaps we should consolidate our JIRA
version numbers.
Let's have more discussion, then run a lazy consensus vote, and get
this documented in the wiki.
>
> --
> 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
>
>
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, 24 Jun 2011 18:43:17 -0300, Massimo Lusetti <ml...@gmail.com>
wrote:
> OpenBSD is an open source operating system project and is by far a lot
> more complicated then a web framework.
> It has a streamlined release process which results in a series of
> successful releases, plus the OpenBSD's snapshots are by far a lot
> more stable then a lot of other operating system "stable releases", I
> see Tapestry release and snapshots story very similar (especially in
> term of stability)
So I think we don't need to call 5.3.0 an alpha release. :) As you
suggested, let's consider snapshots as our alpha releases.
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Massimo Lusetti <ml...@gmail.com>.
On Fri, Jun 24, 2011 at 9:20 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> Hi, Kalle!
>
> I wasn't clear with my words: I don't think 5.3.0 isn't production-ready
> now. I haven't even used it yet :'(, so I can't say anything bad about it. I
> meant 5.3.0 is not final.
>
> 5.3.0, now, is an alpha release, so I think the version and JAR names should
> have some suffix about it somehow. The JBoss conventions, for example, are
> these (http://community.jboss.org/wiki/JBossProjectVersioning):
>
> major.minor.micro.Alpha[n]
> major.minor.micro.Beta[n]
> major.minor.micro.CR[n]
> major.minor.micro.Final
>
> I don't like suffixes for final versions nor the use of uppercase letters
> nor I think Tapestry needs 4 release stages (just alpha or beta and final,
> besides snapshots, should be enough), but I guess we could adapt it.
I don't want to put it on like if something is right and something
else wrong but simply what is right for the project itself so... May I
suggest you to read this[1] presentation and take your conclusions.
OpenBSD is an open source operating system project and is by far a lot
more complicated then a web framework.
It has a streamlined release process which results in a series of
successful releases, plus the OpenBSD's snapshots are by far a lot
more stable then a lot of other operating system "stable releases", I
see Tapestry release and snapshots story very similar (especially in
term of stability)
Cheers
[1] http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/mgp00001.html
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Hi, Kalle!
I wasn't clear with my words: I don't think 5.3.0 isn't production-ready
now. I haven't even used it yet :'(, so I can't say anything bad about it.
I meant 5.3.0 is not final.
5.3.0, now, is an alpha release, so I think the version and JAR names
should have some suffix about it somehow. The JBoss conventions, for
example, are these
(http://community.jboss.org/wiki/JBossProjectVersioning):
major.minor.micro.Alpha[n]
major.minor.micro.Beta[n]
major.minor.micro.CR[n]
major.minor.micro.Final
I don't like suffixes for final versions nor the use of uppercase letters
nor I think Tapestry needs 4 release stages (just alpha or beta and final,
besides snapshots, should be enough), but I guess we could adapt it.
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Kalle Korhonen <ka...@gmail.com>.
On Fri, Jun 24, 2011 at 10:56 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Fri, 24 Jun 2011 14:27:12 -0300, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>> On Fri, 24 Jun 2011 13:42:58 -0300, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> What in particular makes 5.3.0 unstable? Just because it's the first
>>> of 5.3 line or because it's the latest or do you have a specific
>>> concern?
>> I recall Howard having mentioned 5.3.0 being an alpha or beta for the 5.3
>> version. If I'm mistaken, I'm sorry for the confusion . . .
> I was right: 5.3.0 is the first alpha, so it's not what I'd call a stable
> (i.e. production-ready) release.
I.e. it's just because it's the first release of 5.3 line. "Alpha" is
in the eye of a beholder, isn't it? Lots and lots of internals have
changed, but from my experience 5.3.0 is much less an alpha than
5.0.10 was. Many people have been tracking the 5.3.0-SNAPSHOT for
months so it's not like it hasn't gotten any field testing. But the
point I'm trying to make is this: for a new project, would you not
recommend everybody to start using 5.3.0 even if it's considered
unstable? For an existing project, would you upgrade to 5.3.0 right
away? For the former, I'd say absolutely yes, and for the latter, I'd
upgrade when I needed to, and I'd bet that the majority would see it
the same way. It's a framework, not an end-user application, so
"production-ready" depends on your needs. Perhaps the better question:
is 5.3.0 development-ready? I'd say yes.
Kalle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, 24 Jun 2011 14:27:12 -0300, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Fri, 24 Jun 2011 13:42:58 -0300, Kalle Korhonen
> <ka...@gmail.com> wrote:
>
>> What in particular makes 5.3.0 unstable? Just because it's the first
>> of 5.3 line or because it's the latest or do you have a specific
>> concern?
>
> I recall Howard having mentioned 5.3.0 being an alpha or beta for the
> 5.3 version. If I'm mistaken, I'm sorry for the confusion . . .
I was right: 5.3.0 is the first alpha, so it's not what I'd call a stable
(i.e. production-ready) release.
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, 24 Jun 2011 13:42:58 -0300, Kalle Korhonen
<ka...@gmail.com> wrote:
> What in particular makes 5.3.0 unstable? Just because it's the first
> of 5.3 line or because it's the latest or do you have a specific
> concern?
I recall Howard having mentioned 5.3.0 being an alpha or beta for the 5.3
version. If I'm mistaken, I'm sorry for the confusion . . .
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Kalle Korhonen <ka...@gmail.com>.
On Fri, Jun 24, 2011 at 6:17 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Fri, 24 Jun 2011 04:21:34 -0300, Massimo Lusetti <ml...@gmail.com>
> wrote:
>> Any suffix put pressure on the user and almost all users tend to avoid
>> the usage of a "release with a suffix".
> Yep, but we're talking about adding a suffix to non-stable releases (I
> guess), and their use should only be made by people comfortable with it, of
> course.. :)
> I do think that we need a clearer distinction of stable and non-stable
> releases. What in "5.3.0" says it's not a stable release? ;)
What in particular makes 5.3.0 unstable? Just because it's the first
of 5.3 line or because it's the latest or do you have a specific
concern?
Kalle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, 24 Jun 2011 10:31:32 -0300, Massimo Lusetti <ml...@gmail.com>
wrote:
> On Fri, Jun 24, 2011 at 3:17 PM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>
>
>> I do think that we need a clearer distinction of stable and non-stable
>> releases. What in "5.3.0" says it's not a stable release? ;)
>
> The tapestry.apache.org home page where is clear stated that the
> (current) stable release is 5.2.5 ...
> http://tapestry.apache.org/download.html
Maven, Gradle, Ivy, etc users won't even look at this page, going directly
to repository browsers. I do want to have a suffix for non-stable
releases, so users can only look at the version name and know what they're
using, something that doesn't happen today. The simpler and more explicit,
the better. ;)
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, 24 Jun 2011 04:21:34 -0300, Massimo Lusetti <ml...@gmail.com>
wrote:
> Any suffix put pressure on the user and almost all users tend to avoid
> the usage of a "release with a suffix".
Yep, but we're talking about adding a suffix to non-stable releases (I
guess), and their use should only be made by people comfortable with it,
of course.. :)
I do think that we need a clearer distinction of stable and non-stable
releases. What in "5.3.0" says it's not a stable release? ;)
--
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] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Massimo Lusetti <ml...@gmail.com>.
On Thu, Jun 23, 2011 at 7:35 PM, "Ulrich Stärk" <ul...@spielviel.de> wrote:
> 5.2.6 in my scheme would just be that: 5.2.6. We could have had
> 5.2.6-alpha or 5.2.6-RC if we had seen the need for it but there wasn't.
>
> In fact what I proposed would make things even easier and less
> beaurocratic than it is now: No new versions in Jira for unstable releases
> except if we wanted them, no formal votes (since it is declared a test
> package) and no need for all the other formalities (are NOTICE and LICENSE
> files in place, is the source package in order,...) required for a full
> Apache release.
>
> And it would allow users to see the status (alpha, beta, RC) at a glance.
Any suffix put pressure on the user and almost all users tend to avoid
the usage of a "release with a suffix". Please keep the current
scheme, adding the suffix and start using it just make noise if the
project has not a clear and predefined release procedure with (more or
less strict) timelines.
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] new release process (WAS: Re: A question of
vocabulary: release vs. version vs. ???)
Posted by Ulrich Stärk <ul...@spielviel.de>.
5.2.6 in my scheme would just be that: 5.2.6. We could have had
5.2.6-alpha or 5.2.6-RC if we had seen the need for it but there wasn't.
In fact what I proposed would make things even easier and less
beaurocratic than it is now: No new versions in Jira for unstable releases
except if we wanted them, no formal votes (since it is declared a test
package) and no need for all the other formalities (are NOTICE and LICENSE
files in place, is the source package in order,...) required for a full
Apache release.
And it would allow users to see the status (alpha, beta, RC) at a glance.
Uli
Am Do, 23.06.2011, 19:13 schrieb Howard Lewis Ship:
> I tend to like the current approach, especially as it reaches the
> division between a release candidate and a final release. The way we
> currently, retroactively, set the "stability" of the version, based on
> exposure to users, is I think quite sensible AND the Apache Way.
>
> What would 5.2.6 be under your scheme? "5.2-maint-2", perhaps?
>
> What I'd really like to avoid is having to go through the release
> cycle again (to go from, say, 5.3-rc-3 to 5.3 -- the final release).
> Being able to vote up its stability and just adjust the docs, and tell
> the community that the bits they have are now the final release with
> no further download, is a big win in my opinion.
>
> On Thu, Jun 23, 2011 at 6:02 AM, Ulrich Stärk <ul...@spielviel.de> wrote:
>> If you feel that way my second suggestion might deserve some more
>> discussion: Why don't we only
>> release stable versions and provide interested early adopters and
>> testers with test packages that
>> carry clear identifiers like -alpha1, alpha2, RC1 and so on but have the
>> same version number as the
>> to-be-released stable version? We maybe even don't necessarily have to
>> vote on these test packages
>> as they aren't formal releases.
>>
>> Our process could than be something like
>>
>> 1. Set on the version number for the next stable release, e.g. by
>> incrementing the previous version
>> number. For example: next stable release will be 5.3.1.
>> 2. From time to time provide interested early adopters with test
>> packages after shortly discussing
>> on the dev list whether it is alpha, beta or RC quality. For example
>> 5.3.1-alpha2, 5.3.1-RC2
>
> I vaguely remember that there's a requirement that releases
> (definition subject to discussion) require a vote.
>
>> 3. Cut a release once we think a release candidate has reached a point
>> where we can call it stable.
>> E.g. 5.3.1 (without any further additions). Needs a formal vote.
>>
>> Uli
>>
>> On 23.06.2011 14:25, Thiago H. de Paula Figueiredo wrote:
>>> On Thu, 23 Jun 2011 05:15:47 -0300, Ulrich Stärk <ul...@spielviel.de>
>>> wrote:
>>>
>>>> I guess we can continue as before. The only thing I'd like to see
>>>> changed is the addition of the
>>>> status of the release to the version number. I.e. alpha, beta, ...
>>>
>>> Agreed. I'd just leave the stable releases without suffixes and append
>>> alpha, beta, rc or
>>> something like that to emphasize that a release isn't stable.
>>>
>>> To me, the last vote was confusing: it says "5.3.0" without any
>>> indication that it isn't a stable
>>> release. Anyone that doesn't follow the dev list would probably think
>>> it's a stable release, I guess.
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [DISCUSS] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Howard Lewis Ship <hl...@gmail.com>.
I tend to like the current approach, especially as it reaches the
division between a release candidate and a final release. The way we
currently, retroactively, set the "stability" of the version, based on
exposure to users, is I think quite sensible AND the Apache Way.
What would 5.2.6 be under your scheme? "5.2-maint-2", perhaps?
What I'd really like to avoid is having to go through the release
cycle again (to go from, say, 5.3-rc-3 to 5.3 -- the final release).
Being able to vote up its stability and just adjust the docs, and tell
the community that the bits they have are now the final release with
no further download, is a big win in my opinion.
On Thu, Jun 23, 2011 at 6:02 AM, Ulrich Stärk <ul...@spielviel.de> wrote:
> If you feel that way my second suggestion might deserve some more discussion: Why don't we only
> release stable versions and provide interested early adopters and testers with test packages that
> carry clear identifiers like -alpha1, alpha2, RC1 and so on but have the same version number as the
> to-be-released stable version? We maybe even don't necessarily have to vote on these test packages
> as they aren't formal releases.
>
> Our process could than be something like
>
> 1. Set on the version number for the next stable release, e.g. by incrementing the previous version
> number. For example: next stable release will be 5.3.1.
> 2. From time to time provide interested early adopters with test packages after shortly discussing
> on the dev list whether it is alpha, beta or RC quality. For example 5.3.1-alpha2, 5.3.1-RC2
I vaguely remember that there's a requirement that releases
(definition subject to discussion) require a vote.
> 3. Cut a release once we think a release candidate has reached a point where we can call it stable.
> E.g. 5.3.1 (without any further additions). Needs a formal vote.
>
> Uli
>
> On 23.06.2011 14:25, Thiago H. de Paula Figueiredo wrote:
>> On Thu, 23 Jun 2011 05:15:47 -0300, Ulrich Stärk <ul...@spielviel.de> wrote:
>>
>>> I guess we can continue as before. The only thing I'd like to see changed is the addition of the
>>> status of the release to the version number. I.e. alpha, beta, ...
>>
>> Agreed. I'd just leave the stable releases without suffixes and append alpha, beta, rc or
>> something like that to emphasize that a release isn't stable.
>>
>> To me, the last vote was confusing: it says "5.3.0" without any indication that it isn't a stable
>> release. Anyone that doesn't follow the dev list would probably think it's a stable release, I guess.
>>
>
> ---------------------------------------------------------------------
> 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
[DISCUSS] new release process (WAS: Re: A question of vocabulary:
release vs. version vs. ???)
Posted by Ulrich Stärk <ul...@spielviel.de>.
If you feel that way my second suggestion might deserve some more discussion: Why don't we only
release stable versions and provide interested early adopters and testers with test packages that
carry clear identifiers like -alpha1, alpha2, RC1 and so on but have the same version number as the
to-be-released stable version? We maybe even don't necessarily have to vote on these test packages
as they aren't formal releases.
Our process could than be something like
1. Set on the version number for the next stable release, e.g. by incrementing the previous version
number. For example: next stable release will be 5.3.1.
2. From time to time provide interested early adopters with test packages after shortly discussing
on the dev list whether it is alpha, beta or RC quality. For example 5.3.1-alpha2, 5.3.1-RC2
3. Cut a release once we think a release candidate has reached a point where we can call it stable.
E.g. 5.3.1 (without any further additions). Needs a formal vote.
Uli
On 23.06.2011 14:25, Thiago H. de Paula Figueiredo wrote:
> On Thu, 23 Jun 2011 05:15:47 -0300, Ulrich Stärk <ul...@spielviel.de> wrote:
>
>> I guess we can continue as before. The only thing I'd like to see changed is the addition of the
>> status of the release to the version number. I.e. alpha, beta, ...
>
> Agreed. I'd just leave the stable releases without suffixes and append alpha, beta, rc or
> something like that to emphasize that a release isn't stable.
>
> To me, the last vote was confusing: it says "5.3.0" without any indication that it isn't a stable
> release. Anyone that doesn't follow the dev list would probably think it's a stable release, I guess.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: A question of vocabulary: release vs. version vs. ???
Posted by Kalle Korhonen <ka...@gmail.com>.
All software has bugs but we we should really have some faith in our
automated testing suite. The 0 in 5.3.0 already indicates it's the
first release of 5.3 line and as such may have some features that are
not as well field tested than say, features in 5.2.6 release. Version
resolution works best if the version consists only of numbers. We
don't have an internal alpha/beta process and as such, any label we
add to the version is purely subjective. This is not an end user
application but a framework, any drastic issues are very likely to be
discovered during development of the web application. Many of the more
popular open source projects use just a running build number (Jenkins,
Jitsi, etc.) and they seem to be doing fine with that. If we cranked
out RCs, who would really put the effort to thoroughly manually test
them? If we just voted on them on the "yes, I've tried it" basis the
only thing we'd be adding is bureaucracy. Just my two cents and sorry
for the rant but my years in a big corporate have made me quite
allergic to resource waste.
Kalle
On Thu, Jun 23, 2011 at 5:25 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Thu, 23 Jun 2011 05:15:47 -0300, Ulrich Stärk <ul...@spielviel.de> wrote:
>
>> I guess we can continue as before. The only thing I'd like to see changed
>> is the addition of the
>> status of the release to the version number. I.e. alpha, beta, ...
>
> Agreed. I'd just leave the stable releases without suffixes and append
> alpha, beta, rc or something like that to emphasize that a release isn't
> stable.
>
> To me, the last vote was confusing: it says "5.3.0" without any indication
> that it isn't a stable release. Anyone that doesn't follow the dev list
> would probably think it's a stable release, I guess.
>
> --
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: A question of vocabulary: release vs. version vs. ???
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 23 Jun 2011 05:15:47 -0300, Ulrich Stärk <ul...@spielviel.de> wrote:
> I guess we can continue as before. The only thing I'd like to see
> changed is the addition of the
> status of the release to the version number. I.e. alpha, beta, ...
Agreed. I'd just leave the stable releases without suffixes and append
alpha, beta, rc or something like that to emphasize that a release isn't
stable.
To me, the last vote was confusing: it says "5.3.0" without any indication
that it isn't a stable release. Anyone that doesn't follow the dev list
would probably think it's a stable release, I guess.
--
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: A question of vocabulary: release vs. version vs. ???
Posted by Ulrich Stärk <ul...@spielviel.de>.
My understanding of the Apache way on releases is the complete contrary. According to [1] a release
in the Apache sense of the word is something that has "been approved for general public release,
with varying degrees of caveat regarding their perceived quality or potential for change". AIUI that
means that we declare the qualitity of the release beforehand and not afterwards. If we want to take
that approach we should distribute release candidates, which are not Apache releases, and have users
test them. In fact renaming a release, e.g. by promoting it from beta to GA status, might even be
against the rule that no released artifact may ever be modified. See [2] for some guidance. The
right way would be to cut another release.
I guess we can continue as before. The only thing I'd like to see changed is the addition of the
status of the release to the version number. I.e. alpha, beta, ...
Alternatively we can change our process and introduce release candidates. The first stable release
of 5.3 could be 5.3.1 and before we release it we could have 5.3.1-alpha, -alpha2, -beta, -RC1, -RC2
and in the end just 5.3.1. The intermediate releases would be test packages and wouldn't need a
formal vote, thus making it easier for developers to get the code in the open and tested. It would
also greatly help our users understand of what quality the code is. A release with no additions to
the version number is a voted-upon stable release that they can readily use in their applications
whereas -(alpha.*|beta.*|RC.*) releases are releases which we don't deem production-ready.
Uli
[1] http://www.apache.org/dev/release.html#release-typeso
[2] http://incubator.apache.org/guides/releasemanagement.html
On 23.06.2011 05:51, Howard Lewis Ship wrote:
> The Apache way, which I like, is to evaluate a release's stability
> AFTER it is out in user's hands. Thus we vote to release a version,
> say 5.3.217, and after its been out and in use, we vote to upgrade it
> from "beta" (or even "release candidate") to final/stable/GA (choose
> your term). I think its a good system, that reflects the reality of
> complex code and leveraging the community to discover problems.
>
> On Wed, Jun 22, 2011 at 5:40 PM, ael <al...@dash.com.ph> wrote:
>> In Netbeans
>>
>> Release Candidate RC1
>>
>>
>> Release Candidate RC2
>>
>>
>> Final Release
>>
>> --
>> View this message in context: http://tapestry.1045711.n5.nabble.com/A-question-of-vocabulary-release-vs-version-vs-tp4515917p4515999.html
>> Sent from the Tapestry - Dev mailing list archive at Nabble.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: A question of vocabulary: release vs. version vs. ???
Posted by Howard Lewis Ship <hl...@gmail.com>.
The Apache way, which I like, is to evaluate a release's stability
AFTER it is out in user's hands. Thus we vote to release a version,
say 5.3.217, and after its been out and in use, we vote to upgrade it
from "beta" (or even "release candidate") to final/stable/GA (choose
your term). I think its a good system, that reflects the reality of
complex code and leveraging the community to discover problems.
On Wed, Jun 22, 2011 at 5:40 PM, ael <al...@dash.com.ph> wrote:
> In Netbeans
>
> Release Candidate RC1
>
>
> Release Candidate RC2
>
>
> Final Release
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/A-question-of-vocabulary-release-vs-version-vs-tp4515917p4515999.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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: A question of vocabulary: release vs. version vs. ???
Posted by ael <al...@dash.com.ph>.
In Netbeans
Release Candidate RC1
Release Candidate RC2
Final Release
--
View this message in context: http://tapestry.1045711.n5.nabble.com/A-question-of-vocabulary-release-vs-version-vs-tp4515917p4515999.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: A question of vocabulary: release vs. version vs. ???
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Wed, Jun 22, 2011 at 4:56 PM, Bob Harner <bo...@gmail.com> wrote:
> I think the underlying problem is the use of the term "release" for
> non-production-quality code. It shouldn't be necessary to have one
> particular version identified as the "stable version". If it isn't
> fully stable, then it should be a "release candidate", not a
> "release".
>
> Just my 2 cents. I know that's not how the community's release process goes.
Everything can be changed ... not enough is written down. Also, if we
change our nomenclature, we can now go into the CWiki and update old
pages to use the new names, which should help with the confusion
factor.
>
> On Wed, Jun 22, 2011 at 7:46 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> I've been noticing that "release" is a bit overload.
>>
>> We have a product, "Tapestry" or "Apache Tapestry", or "Tapestry 5".
>>
>> We have versions, such a 5.2.6 or 5.3.0.
>>
>> We have releases such as 5.2 or 5.3.
>>
>> However, something seems odd in the phrase "We are pleased to announce
>> the release of Tapestry 5.2.6, the new stable version of Tapestry
>> 5.2.". Actually, that reads well. But I keep having problems
>> elsewhere with the verb "release" vs. the noun "release" (as a
>> sequence of versions). Is it confusing anyone else? Is there a
>> better set of terms we should stick with?
>>
>> --
>> 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
>
>
--
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: A question of vocabulary: release vs. version vs. ???
Posted by Bob Harner <bo...@gmail.com>.
I think the underlying problem is the use of the term "release" for
non-production-quality code. It shouldn't be necessary to have one
particular version identified as the "stable version". If it isn't
fully stable, then it should be a "release candidate", not a
"release".
Just my 2 cents. I know that's not how the community's release process goes.
On Wed, Jun 22, 2011 at 7:46 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I've been noticing that "release" is a bit overload.
>
> We have a product, "Tapestry" or "Apache Tapestry", or "Tapestry 5".
>
> We have versions, such a 5.2.6 or 5.3.0.
>
> We have releases such as 5.2 or 5.3.
>
> However, something seems odd in the phrase "We are pleased to announce
> the release of Tapestry 5.2.6, the new stable version of Tapestry
> 5.2.". Actually, that reads well. But I keep having problems
> elsewhere with the verb "release" vs. the noun "release" (as a
> sequence of versions). Is it confusing anyone else? Is there a
> better set of terms we should stick with?
>
> --
> 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