27 May
2012
27 May
'12
11:52 a.m.
On Sun, May 27, 2012 at 5:43 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
On 05/23/2012 06:51 AM, Thomas Mortagne wrote:
It's not that simple. IMO releasing on Jira mean that what your commit
will go in the following version and that happen the minute you create
the release tag on git.
On Tue, May 22, 2012 at 5:11 PM, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
Not quite, since maven-release.sh should just handle the maven release. But
we could add a pre-release.sh script that handles Jira.
On 05/22/2012 04:52 AM, Vincent Massol wrote:
We should probably move the jira update from push-release.sh to
maven-release.sh and executed right after we finished releasing a
project. It was already a big fuzzy even before since you could have
commons actually released since a long time before you actually
release it on jira (not time to finish the full release, etc...).
On May 22, 2012, at 10:55 AM, Caleb James DeLisle wrote:
> Hi,
>
> I'd like to add staging to our official release process.
> For milestone releases, I propose the staging cycle be for "0 time"
> (this may be revisited later).
+1
> For RC or finals, we place the release in staging and immediately call
> a VOTE to publish the release, this gives our testing team (everybody!) 72
> hours to raise a potential issue.
+1 with the proviso that we need to take that into account when we
publish release dates. When we say that 4.1RC1 will be released on 11th of
June, I guess it means we need to release RC1 on 11th - 72 hours then?
Sounds good, to prevent issues having their fix-for version set as the
released version, it makes sense to release on jira right away but post-date
the release so that dates line up.
Anyway this is something we can leave open to experimentation until the
right decision makes itself obvious.
Caleb
>
>> Why:
>>
>> #1. After some chat on IRC I decided that it is advantageous to move
>> toward a faster release cycle and begin moving away from milestone releases
>> in favor of staging. This will set the stage for the release method we will
>> need.
>>
>> #2. Staging is easy, I've modified the release script to include
>> staging and with the script, it is a simple matter of about 5 clicks on
>> nexus to "login", "close repository", "release
repository".
>>
>> #3. Staging is safe, the RM need not worry about fat fingers breaking
>> the release, all it costs is time.
>>
>> #4. The release process should be as close to the same as possible for
>> milestone and RC/final releases. This simplifies scripting of the process,
>> decreases the amount the RM must remember and makes every milestone release
>> a rehearsal.
>>
>> #5. Everybody else is doing it (is that even a reason?!)
>>
>>
>> Mandatory?
>> I would rather impress the RM with how easy and helpful staging can be
>> than bind him with rules.
>> If I had followed the existing process to the letter, I would not have
>> had any experience with staging to begin with.
>> In the interest of continuous improvement I would like to make this a
>> strong recommendation, not a strict rule.
>>
>>
>> Here's my +1
>
>
> +1
+1