You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2005/01/19 19:17:44 UTC
Versioning work-in-development (Re: svn commit: r125632 -
/struts/el/trunk/project.xml)
This raises a question which I don't feel we've really pinned down
yet -- how should we version artifacts between releases? Right now,
the result of maven jar for struts-el is "struts-el-1.2.6.jar", which
is misleading.
This is independent of another question, which we should also
probably discuss, which is how we version non-core artifacts. I
generally prefer sharing version numbers -- I find the J2EE
methodology of rolling in a number of disparate version numbers into
a single release continually confusing, although I think that Ted has
suggested it as the approach for future Struts releases once we have
our pieces all broken out. I know that if we want things to have
their own release cycle, then we may not simply be able to share the
major "Struts version number", but like I said, I'm not real fond of
the only other alternative I have thought of.
I admit to having no solid proposal for either of these things.
For between-release artifacts, I have seen someone use "SNAPSHOT" in
a version name, which I would recommend against, as Maven always
tries to download dependencies which contain that string, something
which quickly becomes tiresome. I would prefer that we not use real
version numbers in the project.xml file until the moment when a
release is being cut, to avoid confusion.
In my uncommitted work on the ActionContext, I am using
"struts-1.3.0-dev". I think using the expected next release number
plus "-dev" is a decent compromise, but I'm happy to hear other ideas.
Joe
At 5:46 PM +0000 1/19/05, jmitchell@apache.org wrote:
>Author: jmitchell
>Date: Wed Jan 19 09:46:35 2005
>New Revision: 125632
>
>URL: http://svn.apache.org/viewcvs?view=rev&rev=125632
>Log:
>el now builds a good distribution (well, with maven anyway)
>Modified:
> struts/el/trunk/project.xml
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Versioning work-in-development (Re: svn commit: r125632 - /struts/el/trunk/project.xml)
Posted by Rob Leland <le...@speakeasy.net>.
Craig McClanahan wrote:
>On Wed, 19 Jan 2005 22:12:45 -0500, Robert Leland <rl...@apache.org> wrote:
>
>
>>For the in between official releases for our project at work I created a
>>'all-versioned' target
>>that uses ants 'propertyFile' task to automatically increment a build
>>number.
>>This build number is stored in the ant generated manifest file of the
>>built jar/war file.
>>For the first 'versioned' build, ant either copies the
>>version.properties.sample file
>>to version.properties or creates a version.properties file from scratch
>>if the sample doesn't exist.
>>A base build number is specified such as 1.3.0 to that a forth build
>>number is added
>>so the first build is 1.3.0.1, second 1.3.0.2 etc...
>>
>>
>
>We do this kind of thing on my day-job projects as well ... but it
>only works when there is one authoritative source of builds that have
>"real" version numbers. (For Creator, we have a Release Engineering
>group that does just this kind of thing, and nobody else can generate
>an "official" build.)
>
>What happens when some random downloader of the source code generates
>a build and happens to make it available to other folks? Result is a
>second (or third, or ...) instance of the same build number, and
>confusion in the world over which one is official.
>
>
Yes it has that short fall but as I said it has the builders name which
helps.
>No, change "random downloader" to "Gump" (which also publishes its
>artifacts, at least for a short amount of time) and see what happens
>...
>
>
>
>>Since Craig does the nightly builds there would be little danger say
>>multiple 1.3.0.23 floating around
>>that were built at different dates, especially since the manefest file
>>has the name of the person who built it also.
>>It would take very little to add this to the current build process.
>>
>>
>>
>
>You could say that about nightly builds ... I don't see how you deal
>with builds from other sources.
>
>In the mean time, I like Martin's suggestion of a "-dev" suffix, which
>is a practice at least some of the commons packages follow already.
>
>
>
>>-Rob
>>
>>
>
>Craig
>
>
>
>>Martin Cooper wrote:
>>
>>
>>
>>>I would suggest the following:
>>>
>>>* While in development, we continue to use the "-dev" suffix on the
>>>version number, with the version number itself being the next
>>>anticipated build.
>>>
>>>* Starting now, all subprojects use 1.3.0-dev as their version number.
>>>This is probably the only time they'll ever be in sync, but I think we
>>>should all start on the same page.
>>>
>>>* Subprojects increase their version numbers as needed, with no need
>>>to sync up with any other subproject's version number.
>>>
>>>As for bundles, I'm not totally convinced that we need them,
>>>especially as more people move to Maven. If we do decide to provide
>>>them, then I also don't have any good ideas for versioning them, or
>>>even how to define them, in terms of subprojects and when we would
>>>create a new one. (Would we create a new one each time any subproject
>>>has a new release? That would be a pain, and probably annoying /
>>>confusing to users. But if not, what would be the criteria for a new
>>>bundle?)
>>>
>>>As you mentioned, Joe, the J2EE numbering doesn't really tell you very
>>>much. It makes for interesting Cactus versioning, too, since Cactus
>>>embeds both its version number and the J2EE version number in its
>>>distro names. Yuk.
>>>
>>>I'd say let's forget about bundles, at least for the time being, and
>>>simply focus on getting the various subprojects sorted out and
>>>released in their new incarnations. Then we can see what the uptake
>>>is, and what the community thinks with respect to keeping things
>>>separate or defining some kind of bundling scheme.
>>>
>>>--
>>>Martin Cooper
>>>
>>>
>>>On Wed, 19 Jan 2005 12:17:44 -0600, Joe Germuska <Jo...@germuska.com> wrote:
>>>
>>>
>>>
>>>
>>>>This raises a question which I don't feel we've really pinned down
>>>>yet -- how should we version artifacts between releases? Right now,
>>>>the result of maven jar for struts-el is "struts-el-1.2.6.jar", which
>>>>is misleading.
>>>>
>>>>This is independent of another question, which we should also
>>>>probably discuss, which is how we version non-core artifacts. I
>>>>generally prefer sharing version numbers -- I find the J2EE
>>>>methodology of rolling in a number of disparate version numbers into
>>>>a single release continually confusing, although I think that Ted has
>>>>suggested it as the approach for future Struts releases once we have
>>>>our pieces all broken out. I know that if we want things to have
>>>>their own release cycle, then we may not simply be able to share the
>>>>major "Struts version number", but like I said, I'm not real fond of
>>>>the only other alternative I have thought of.
>>>>
>>>>I admit to having no solid proposal for either of these things.
>>>>
>>>>For between-release artifacts, I have seen someone use "SNAPSHOT" in
>>>>a version name, which I would recommend against, as Maven always
>>>>tries to download dependencies which contain that string, something
>>>>which quickly becomes tiresome. I would prefer that we not use real
>>>>version numbers in the project.xml file until the moment when a
>>>>release is being cut, to avoid confusion.
>>>>
>>>>In my uncommitted work on the ActionContext, I am using
>>>>"struts-1.3.0-dev". I think using the expected next release number
>>>>plus "-dev" is a decent compromise, but I'm happy to hear other ideas.
>>>>
>>>>Joe
>>>>
>>>>At 5:46 PM +0000 1/19/05, jmitchell@apache.org wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Author: jmitchell
>>>>>Date: Wed Jan 19 09:46:35 2005
>>>>>New Revision: 125632
>>>>>
>>>>>URL: http://svn.apache.org/viewcvs?view=rev&rev=125632
>>>>>Log:
>>>>>el now builds a good distribution (well, with maven anyway)
>>>>>Modified:
>>>>> struts/el/trunk/project.xml
>>>>>
>>>>>
>>>>>
>>>>>
>>>>--
>>>>Joe Germuska
>>>>Joe@Germuska.com
>>>>http://blog.germuska.com
>>>>"Narrow minds are weapons made for mass destruction" -The Ex
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Versioning work-in-development (Re: svn commit: r125632 - /struts/el/trunk/project.xml)
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 19 Jan 2005 22:12:45 -0500, Robert Leland <rl...@apache.org> wrote:
> For the in between official releases for our project at work I created a
> 'all-versioned' target
> that uses ants 'propertyFile' task to automatically increment a build
> number.
> This build number is stored in the ant generated manifest file of the
> built jar/war file.
> For the first 'versioned' build, ant either copies the
> version.properties.sample file
> to version.properties or creates a version.properties file from scratch
> if the sample doesn't exist.
> A base build number is specified such as 1.3.0 to that a forth build
> number is added
> so the first build is 1.3.0.1, second 1.3.0.2 etc...
We do this kind of thing on my day-job projects as well ... but it
only works when there is one authoritative source of builds that have
"real" version numbers. (For Creator, we have a Release Engineering
group that does just this kind of thing, and nobody else can generate
an "official" build.)
What happens when some random downloader of the source code generates
a build and happens to make it available to other folks? Result is a
second (or third, or ...) instance of the same build number, and
confusion in the world over which one is official.
No, change "random downloader" to "Gump" (which also publishes its
artifacts, at least for a short amount of time) and see what happens
...
>
> Since Craig does the nightly builds there would be little danger say
> multiple 1.3.0.23 floating around
> that were built at different dates, especially since the manefest file
> has the name of the person who built it also.
> It would take very little to add this to the current build process.
>
You could say that about nightly builds ... I don't see how you deal
with builds from other sources.
In the mean time, I like Martin's suggestion of a "-dev" suffix, which
is a practice at least some of the commons packages follow already.
> -Rob
Craig
> Martin Cooper wrote:
>
> >I would suggest the following:
> >
> >* While in development, we continue to use the "-dev" suffix on the
> >version number, with the version number itself being the next
> >anticipated build.
> >
> >* Starting now, all subprojects use 1.3.0-dev as their version number.
> >This is probably the only time they'll ever be in sync, but I think we
> >should all start on the same page.
> >
> >* Subprojects increase their version numbers as needed, with no need
> >to sync up with any other subproject's version number.
> >
> >As for bundles, I'm not totally convinced that we need them,
> >especially as more people move to Maven. If we do decide to provide
> >them, then I also don't have any good ideas for versioning them, or
> >even how to define them, in terms of subprojects and when we would
> >create a new one. (Would we create a new one each time any subproject
> >has a new release? That would be a pain, and probably annoying /
> >confusing to users. But if not, what would be the criteria for a new
> >bundle?)
> >
> >As you mentioned, Joe, the J2EE numbering doesn't really tell you very
> >much. It makes for interesting Cactus versioning, too, since Cactus
> >embeds both its version number and the J2EE version number in its
> >distro names. Yuk.
> >
> >I'd say let's forget about bundles, at least for the time being, and
> >simply focus on getting the various subprojects sorted out and
> >released in their new incarnations. Then we can see what the uptake
> >is, and what the community thinks with respect to keeping things
> >separate or defining some kind of bundling scheme.
> >
> >--
> >Martin Cooper
> >
> >
> >On Wed, 19 Jan 2005 12:17:44 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> >
> >
> >>This raises a question which I don't feel we've really pinned down
> >>yet -- how should we version artifacts between releases? Right now,
> >>the result of maven jar for struts-el is "struts-el-1.2.6.jar", which
> >>is misleading.
> >>
> >>This is independent of another question, which we should also
> >>probably discuss, which is how we version non-core artifacts. I
> >>generally prefer sharing version numbers -- I find the J2EE
> >>methodology of rolling in a number of disparate version numbers into
> >>a single release continually confusing, although I think that Ted has
> >>suggested it as the approach for future Struts releases once we have
> >>our pieces all broken out. I know that if we want things to have
> >>their own release cycle, then we may not simply be able to share the
> >>major "Struts version number", but like I said, I'm not real fond of
> >>the only other alternative I have thought of.
> >>
> >>I admit to having no solid proposal for either of these things.
> >>
> >>For between-release artifacts, I have seen someone use "SNAPSHOT" in
> >>a version name, which I would recommend against, as Maven always
> >>tries to download dependencies which contain that string, something
> >>which quickly becomes tiresome. I would prefer that we not use real
> >>version numbers in the project.xml file until the moment when a
> >>release is being cut, to avoid confusion.
> >>
> >>In my uncommitted work on the ActionContext, I am using
> >>"struts-1.3.0-dev". I think using the expected next release number
> >>plus "-dev" is a decent compromise, but I'm happy to hear other ideas.
> >>
> >>Joe
> >>
> >>At 5:46 PM +0000 1/19/05, jmitchell@apache.org wrote:
> >>
> >>
> >>>Author: jmitchell
> >>>Date: Wed Jan 19 09:46:35 2005
> >>>New Revision: 125632
> >>>
> >>>URL: http://svn.apache.org/viewcvs?view=rev&rev=125632
> >>>Log:
> >>>el now builds a good distribution (well, with maven anyway)
> >>>Modified:
> >>> struts/el/trunk/project.xml
> >>>
> >>>
> >>--
> >>Joe Germuska
> >>Joe@Germuska.com
> >>http://blog.germuska.com
> >>"Narrow minds are weapons made for mass destruction" -The Ex
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Versioning work-in-development (Re: svn commit: r125632 - /struts/el/trunk/project.xml)
Posted by Robert Leland <rl...@apache.org>.
For the in between official releases for our project at work I created a
'all-versioned' target
that uses ants 'propertyFile' task to automatically increment a build
number.
This build number is stored in the ant generated manifest file of the
built jar/war file.
For the first 'versioned' build, ant either copies the
version.properties.sample file
to version.properties or creates a version.properties file from scratch
if the sample doesn't exist.
A base build number is specified such as 1.3.0 to that a forth build
number is added
so the first build is 1.3.0.1, second 1.3.0.2 etc...
Since Craig does the nightly builds there would be little danger say
multiple 1.3.0.23 floating around
that were built at different dates, especially since the manefest file
has the name of the person who built it also.
It would take very little to add this to the current build process.
-Rob
Martin Cooper wrote:
>I would suggest the following:
>
>* While in development, we continue to use the "-dev" suffix on the
>version number, with the version number itself being the next
>anticipated build.
>
>* Starting now, all subprojects use 1.3.0-dev as their version number.
>This is probably the only time they'll ever be in sync, but I think we
>should all start on the same page.
>
>* Subprojects increase their version numbers as needed, with no need
>to sync up with any other subproject's version number.
>
>As for bundles, I'm not totally convinced that we need them,
>especially as more people move to Maven. If we do decide to provide
>them, then I also don't have any good ideas for versioning them, or
>even how to define them, in terms of subprojects and when we would
>create a new one. (Would we create a new one each time any subproject
>has a new release? That would be a pain, and probably annoying /
>confusing to users. But if not, what would be the criteria for a new
>bundle?)
>
>As you mentioned, Joe, the J2EE numbering doesn't really tell you very
>much. It makes for interesting Cactus versioning, too, since Cactus
>embeds both its version number and the J2EE version number in its
>distro names. Yuk.
>
>I'd say let's forget about bundles, at least for the time being, and
>simply focus on getting the various subprojects sorted out and
>released in their new incarnations. Then we can see what the uptake
>is, and what the community thinks with respect to keeping things
>separate or defining some kind of bundling scheme.
>
>--
>Martin Cooper
>
>
>On Wed, 19 Jan 2005 12:17:44 -0600, Joe Germuska <Jo...@germuska.com> wrote:
>
>
>>This raises a question which I don't feel we've really pinned down
>>yet -- how should we version artifacts between releases? Right now,
>>the result of maven jar for struts-el is "struts-el-1.2.6.jar", which
>>is misleading.
>>
>>This is independent of another question, which we should also
>>probably discuss, which is how we version non-core artifacts. I
>>generally prefer sharing version numbers -- I find the J2EE
>>methodology of rolling in a number of disparate version numbers into
>>a single release continually confusing, although I think that Ted has
>>suggested it as the approach for future Struts releases once we have
>>our pieces all broken out. I know that if we want things to have
>>their own release cycle, then we may not simply be able to share the
>>major "Struts version number", but like I said, I'm not real fond of
>>the only other alternative I have thought of.
>>
>>I admit to having no solid proposal for either of these things.
>>
>>For between-release artifacts, I have seen someone use "SNAPSHOT" in
>>a version name, which I would recommend against, as Maven always
>>tries to download dependencies which contain that string, something
>>which quickly becomes tiresome. I would prefer that we not use real
>>version numbers in the project.xml file until the moment when a
>>release is being cut, to avoid confusion.
>>
>>In my uncommitted work on the ActionContext, I am using
>>"struts-1.3.0-dev". I think using the expected next release number
>>plus "-dev" is a decent compromise, but I'm happy to hear other ideas.
>>
>>Joe
>>
>>At 5:46 PM +0000 1/19/05, jmitchell@apache.org wrote:
>>
>>
>>>Author: jmitchell
>>>Date: Wed Jan 19 09:46:35 2005
>>>New Revision: 125632
>>>
>>>URL: http://svn.apache.org/viewcvs?view=rev&rev=125632
>>>Log:
>>>el now builds a good distribution (well, with maven anyway)
>>>Modified:
>>> struts/el/trunk/project.xml
>>>
>>>
>>--
>>Joe Germuska
>>Joe@Germuska.com
>>http://blog.germuska.com
>>"Narrow minds are weapons made for mass destruction" -The Ex
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Versioning work-in-development (Re: svn commit: r125632 - /struts/el/trunk/project.xml)
Posted by Martin Cooper <mf...@gmail.com>.
I would suggest the following:
* While in development, we continue to use the "-dev" suffix on the
version number, with the version number itself being the next
anticipated build.
* Starting now, all subprojects use 1.3.0-dev as their version number.
This is probably the only time they'll ever be in sync, but I think we
should all start on the same page.
* Subprojects increase their version numbers as needed, with no need
to sync up with any other subproject's version number.
As for bundles, I'm not totally convinced that we need them,
especially as more people move to Maven. If we do decide to provide
them, then I also don't have any good ideas for versioning them, or
even how to define them, in terms of subprojects and when we would
create a new one. (Would we create a new one each time any subproject
has a new release? That would be a pain, and probably annoying /
confusing to users. But if not, what would be the criteria for a new
bundle?)
As you mentioned, Joe, the J2EE numbering doesn't really tell you very
much. It makes for interesting Cactus versioning, too, since Cactus
embeds both its version number and the J2EE version number in its
distro names. Yuk.
I'd say let's forget about bundles, at least for the time being, and
simply focus on getting the various subprojects sorted out and
released in their new incarnations. Then we can see what the uptake
is, and what the community thinks with respect to keeping things
separate or defining some kind of bundling scheme.
--
Martin Cooper
On Wed, 19 Jan 2005 12:17:44 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> This raises a question which I don't feel we've really pinned down
> yet -- how should we version artifacts between releases? Right now,
> the result of maven jar for struts-el is "struts-el-1.2.6.jar", which
> is misleading.
>
> This is independent of another question, which we should also
> probably discuss, which is how we version non-core artifacts. I
> generally prefer sharing version numbers -- I find the J2EE
> methodology of rolling in a number of disparate version numbers into
> a single release continually confusing, although I think that Ted has
> suggested it as the approach for future Struts releases once we have
> our pieces all broken out. I know that if we want things to have
> their own release cycle, then we may not simply be able to share the
> major "Struts version number", but like I said, I'm not real fond of
> the only other alternative I have thought of.
>
> I admit to having no solid proposal for either of these things.
>
> For between-release artifacts, I have seen someone use "SNAPSHOT" in
> a version name, which I would recommend against, as Maven always
> tries to download dependencies which contain that string, something
> which quickly becomes tiresome. I would prefer that we not use real
> version numbers in the project.xml file until the moment when a
> release is being cut, to avoid confusion.
>
> In my uncommitted work on the ActionContext, I am using
> "struts-1.3.0-dev". I think using the expected next release number
> plus "-dev" is a decent compromise, but I'm happy to hear other ideas.
>
> Joe
>
> At 5:46 PM +0000 1/19/05, jmitchell@apache.org wrote:
> >Author: jmitchell
> >Date: Wed Jan 19 09:46:35 2005
> >New Revision: 125632
> >
> >URL: http://svn.apache.org/viewcvs?view=rev&rev=125632
> >Log:
> >el now builds a good distribution (well, with maven anyway)
> >Modified:
> > struts/el/trunk/project.xml
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org