uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <richard.eck...@gmail.com>
Subject Re: Bug in the release process: scm location in release pom points to rc
Date Thu, 05 Sep 2013 10:48:23 GMT
I'm fine with not marking the RCs in SVN. Do we need a vote to change
the process or can we simply update the release guide?

-- Richard

On 03.09.2013, at 16:20, Marshall Schor <msa@schor.com> wrote:

> On 9/2/2013 10:14 AM, Richard Eckart de Castilho wrote:
>> Am 02.09.2013 um 15:26 schrieb Marshall Schor <msa@schor.com>:
>> 
>>> On 8/31/2013 2:12 PM, Richard Eckart de Castilho wrote:
>>>> There is a "bug" in the release process currently used for UIMA projects.
>>>> 
>>>> The practice is to make rc release by
>>>> - setting the version to the final version
>>>> - changing the svn tag location adding -rcX
>>>> 
>>>> The practice to accept a release is
>>>> - rename the -rcX tag in svn, removing -rcX
>>>> 
>>>> The bug is, that the SCM locations in the release POM are then pointing to
the rc SVN location.
>>>> 
>>>> What's worse is, that after the release, the accepted rc folder in SVN is
renamed, removing the "-rcX". Consequently, the SVM location in the POM points to nowhere.
>>>> 
>>>> Two problems:
>>>> 
>>>> - the SCM location should point to a non-RC tag
>>>> - the tag pointed to should not be systematically renamed/removed, making
the SCM location basically worthless
>>>> 
>>>> Can we do something about this?
>>> One "easy" thing to do is to change our practice, to having mvn release:prepare
>>> take the default for the svn tag, without the -rcX suffix.
>>> 
>>> This would make both of these problems go away.
>>> 
>>> It would require manually deleting the svn tag for a "failed" release try, so
it
>>> could be recreated by the mvn release:prepare.
>>> 
>>> I'm ok with this, given that SVN will keep a history of the rc's if anyone
>>> needed to go to a previous one for some reason that I can't think of.
>>> 
>>> WDYT?
>> If we wanted to keep the failed RC tags explicitly, we could manually renamed the
failed rc tags to -rcX.
>> 
>> I'd be both with either solution: delete failed RCs or renamed them after failing.
> 
> I have never had a reason to look up a failed rc, myself.  I can imagine one
> use-case - suppose a "tester" got confused as to which rc they had downloaded
> /tested - they can checkout / compare various rc's against what they have
> locally to see which rc they have.  This is versus our current practice, where
> the checkout would identify which rc it was. 
> 
> Of course, people who checkout for testing could check out a tag (without the
> rc) into a local working copy directory which included the rc, to avoid confusion.
> 
> So this seems a pretty weak reason to me to worry about this - so I'm in favor
> of switching our practice to just using the recommended name suggested by mvn
> release:prepare, without an -rc suffix.
> 
> -Marshall
>> 
>> -- Richard
>> 
>>> -Marshall
>>>> Cheers,
>>>> 
>>>> -- Richard


Mime
View raw message