Martin, Just to be clear, I am not saying that the Maven's way is the right way. There are two way to do releases: manually or batch. In manual mode, the user is prompted to name the tag. In batch mode, Maven creates the tag by its own naming standards (projectname-version).
Paul On Thu, Dec 17, 2009 at 5:44 PM, Martin Cooper <mart...@apache.org> wrote: > On Thu, Dec 17, 2009 at 3:40 PM, Paul Benedict <pbened...@apache.org> wrote: >> I am saying that if we keep the uppercase and underscore convention, >> we can't accept the default of Maven's tag names. The release manager >> just has to continue using the format we do today. That's all. > > I was trying to understand the disappointment you expressed. My own > disappointment, to the extent that I have any, is that we let the > Maven team define the standards that we use for our releases, but as I > said before, I'm not married to keeping the "old" way. > > -- > Martin Cooper > > >> Paul >> >> On Thu, Dec 17, 2009 at 5:38 PM, Martin Cooper <mart...@apache.org> wrote: >>> 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 >>> >>> >> >> --------------------------------------------------------------------- >> 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