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

Reply via email to