If you look at the contents of https://svn.apache.org/repos/asf/commons/proper/io/tags, you will see that the _existing convention_, dating back to 2.2, is to use the maven-release-plugin to create a tag like commons-io-xxx, and then to later add a tag for xxx.
If someone doesn't like that _existing convention_, someone can start a vote to change it. And stop accusing me of inappropriate innovation. I'm done here. On Mon, May 9, 2016 at 5:44 AM, sebb <seb...@gmail.com> wrote: > On 9 May 2016 at 07:43, Benedikt Ritter <brit...@apache.org> wrote: >> Hi, >> >> sebb <seb...@gmail.com> schrieb am So., 8. Mai 2016 um 14:47 Uhr: >> >>> On 8 May 2016 at 13:43, sebb <seb...@gmail.com> wrote: >>> > On 8 May 2016 at 13:16, Benedikt Ritter <brit...@apache.org> wrote: >>> >> Benson Margulies <bimargul...@gmail.com> schrieb am So., 8. Mai 2016 um >>> >> 14:06 Uhr: >>> >> >>> >>> I just made 2.5 look like 2.4. How is that a change that requires >>> >>> discussion? Shouldn't it have been noticed and discussed when it was >>> >>> done for 2.4? >>> >>> >>> >> >>> >> I see sebb's point. It is good to have a name tags uniformly. Some >>> >> components have a wild mix of different casing in the tag names. My >>> >> personal opinion is, that the tag names should just the release version >>> >> number, but that is a different discussion. >>> >> >>> >> If this change has been made to make tag names uniform in commons-io, I >>> >> don't see a problem with that. >>> > >>> > I agree that having mixed names for tags is confusing, but so is >>> > having multiple tags for the same release. >>> > >>> > And in order to fix IO properly it would require many more duplicate >>> > tags; the current list is: >>> > >>> > 2.2/ >>> > 2.3/ >>> > 2.4/ >>> > 2.5/ >>> > IO_1_0/ >>> > IO_1_1/ >>> > IO_1_2/ >>> > IO_1_3/ >>> > IO_1_3_1/ >>> > commons-io-1.3.2/ >>> > commons-io-1.4/ >>> > commons-io-2.0/ >>> > commons-io-2.0.1/ >>> > commons-io-2.1/ >>> > commons-io-2.5/ >>> > >>> > [For simplicity I have omitted the RCs] >>> > >>> > The addition of the 2.5 tag did little to fix the problem. >>> > >>> > And I don't agree that bare version numbers are best for Commons. >>> > When the tag is checked out, it is not clear what component it is for. >>> >> >> That's only true for SVN based components. But as I said, that is a >> different discussion :-) >> >> >>> >>> Forgot to say: the tags are also noted in the released POM >>> >>> So the 2.5/pom.xml is inconsistent with its location. >>> >>> If we want to change the convention going forward, we should vote on that. >>> But we cannot/must not change history. >>> >> >> Okay, so what is your proposal? Roll back the commit and then vote on a new >> convention? > > Although we don't generally allow tags to be deleted, I think it would > be OK here. > The log message should make it clear what the 'real' tag is called. > > A convention needs discussion before a vote. > >> Benedikt >> >> >>> >>> >> Benedikt >>> >> >>> >> >>> >>> >>> >>> >>> >>> On Sun, May 8, 2016 at 7:17 AM, sebb <seb...@gmail.com> wrote: >>> >>> > On 6 May 2016 at 13:16, <bimargul...@apache.org> wrote: >>> >>> >> Author: bimargulies >>> >>> >> Date: Fri May 6 12:16:39 2016 >>> >>> >> New Revision: 1742534 >>> >>> >> >>> >>> >> URL: http://svn.apache.org/viewvc?rev=1742534&view=rev >>> >>> >> Log: >>> >>> >> Honor both tagging conventions? >>> >>> > >>> >>> > This is potentially confusing. >>> >>> > >>> >>> > I think it should have been discussed first. >>> >>> > >>> >>> >> Added: >>> >>> >> commons/proper/io/tags/2.5/ >>> >>> >> - copied from r1742533, commons/proper/io/tags/commons-io-2.5/ >>> >>> >> >>> >>> > >>> >>> > --------------------------------------------------------------------- >>> >>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> >>> > For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > >>> >>> >>> >>> --------------------------------------------------------------------- >>> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org