+1 The RC1 and Final are tested before the actual release, but it is not nice because while testing the latest snapshot (before RC or Final), developers can still commit, meaning that some bugs might be introduced while I was testing, or incomplete commits (work not done) could be reported as bugs.
Regards, Sorin B. On Sun, May 27, 2012 at 12:52 PM, Thomas Mortagne <[email protected]> wrote: > On Sun, May 27, 2012 at 5:43 AM, Sergiu Dumitriu <[email protected]> wrote: >> On 05/23/2012 06:51 AM, Thomas Mortagne wrote: >>> >>> On Tue, May 22, 2012 at 5:11 PM, Caleb James DeLisle >>> <[email protected]> wrote: >>>> >>>> >>>> >>>> On 05/22/2012 04:52 AM, Vincent Massol wrote: >>>>> >>>>> >>>>> 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. >>> >>> >>> 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...). >> >> >> Not quite, since maven-release.sh should just handle the maven release. But >> we could add a pre-release.sh script that handles Jira. > > 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. > >> >> >>>> >>>> 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 >> >> >> >> -- >> Sergiu Dumitriu >> http://purl.org/net/sergiu/ >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
