On Thu, Dec 17, 2009 at 3:34 PM, Paul Benedict <pbened...@apache.org> wrote: > I have nothing against continuing the way *we* do it, but Maven > doesn't do it this way. Taking the defaults provided by the Maven > Release Plugin will create tag names like "struts-1.3.11" over > "STRUTS_1_3_11". > > Either way we decide, it is not a major loss for the other side, but > not able to accept Maven defaults is a bit disappointing.
Who / what is not able to accept them? -- Martin Cooper > Paul > > On Thu, Dec 17, 2009 at 4:08 PM, Martin Cooper <mart...@apache.org> wrote: >> On Thu, Dec 17, 2009 at 12:27 PM, Wes Wannemacher <w...@wantii.com> wrote: >>> Not to split hairs, Lukasz, but this is the "released" pom - >>> >>> https://svn.apache.org/repos/asf/struts/maven/tags/struts2-archetype-starter-2.1.8.1/pom.xml >>> >>> Which looks fine. >>> >>> When I was checking this, it reminded me of something I have been >>> meaning to ask. If you look at the tag name that Lukasz used - >>> "struts2-archetype-starter-2.1.8.1" But, somewhere in our docs, we use >>> a tag name like this - "STRUTS2_ARCHETYPE_STARTER_2_1_8_1" which you >>> can see here - >>> >>> https://svn.apache.org/repos/asf/struts/struts2/tags/ >>> >>> The tag name that Lukasz used is what the release plugin defaults >>> to... Is there a reason we don't use it? I'm all about sticking to >>> defaults (since it tends to make the documentation easier), so I am >>> wondering if there is a reason, other than "that's the way we always >>> did it" >> >> To my knowledge, "that's the way we always did it" is the correct >> answer here, assuming the question is "upper case and underscores" >> versus "lower case and dashes". As you can see here, the former has >> been used since the very beginning of Struts, almost 10 years ago: >> >> http://svn.apache.org/repos/asf/struts/struts1/tags/ >> >> Bear in mind that there's an enormous amount of Struts history prior >> to us adopting Maven, let alone the Maven release plugin, so this is >> hardly surprising. That the Maven default is different is simply the >> result of the Maven team picking the wrong default release naming >> scheme. :-p >> >> If there's an easy way to tell the release plugin to use "upper case >> and underscores" instead of "lower case and dashes", the continuity >> would be nice, since there's no other good reason to change what we've >> been doing for so long. If there isn't an easy way to do that, though, >> and it's a nuisance to change the default for some reason, then I'm >> not dead set against adopting the Maven way. >> >> -- >> Martin Cooper >> >> >>> -Wes >>> >>> On Wed, Dec 16, 2009 at 12:50 PM, Lukasz Lenart >>> <lukasz.len...@googlemail.com> wrote: >>>> 2009/12/16 Martin Cooper <mart...@apache.org>: >>>>> In Lukasz's checkins just now, I see version numbers being changed to >>>>> 2.1.8-SNAPSHOT. Maybe I'm misinterpreting what's going on, but that >>>>> seems like going backwards. We already have a 2.1.8 and a 2.1.8.1, so >>>>> it seems to me that any snapshot version we should be using now would >>>>> need to be 2.1.9-SNAPSHOT, no? After all, snapshots precede the number >>>>> they're attached to, in terms of version number ordering. >>>> >>>> I just switched to 2.1.8-SNAPSHOT because Maven release plugin is >>>> complaining - after I did the release, everything is ok, please check >>>> already released pom.xml >>>> >>>> https://svn.apache.org/repos/asf/struts/maven/trunk/struts2-archetype-blank/pom.xml >>>> >>>> >>>> Regards >>>> -- >>>> Lukasz >>>> http://www.lenart.org.pl/ >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>>> For additional commands, e-mail: dev-h...@struts.apache.org >>>> >>>> >>> >>> >>> >>> -- >>> Wes Wannemacher >>> >>> Head Engineer, WanTii, Inc. >>> Need Training? Struts, Spring, Maven, Tomcat... >>> Ask me for a quote! >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
