Re: [xwiki-devs] [VOTE] Change the release cycle to 1 month (RESULT)

[Vincent Massol]

Result: 
+1 vincent
+0 caty
+1 marius
+1 thomas
+1 guillaume

The vote is passed. 

I’ve now updated our doc at 
http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices

Let’s start applying this for 8.4 now.

Thanks
-Vincent

> On 15 Sep 2016, at 11:18, Vincent Massol  wrote:
> 
> Hi devs,
> 
> Executive summary:
> * Replace our 3 month release cycle by a 1 month release cycle.
> 
> Needs and advantages:
> * Be able to get our changes faster to our users. Importantly, bugfixes are 
> released faster to users. Note: it’s not because we release faster that our 
> users have to upgrade as fast. They can skip some versions if they want/need.
> * Be able to get more feedback more quickly from users. Right now, most (if 
> not all) of our users are testing only final versions. They’re not testing 
> milestones or RCs and thus we usually only know about problems after the 
> final has been released and we incorporate the change in the next one (to be 
> released 3 months later) or we have to do a bugfix release.
> * Get closer to cloud needs. Nowadays, could offerings happen more and more 
> and operating a cloud means bringing improvements and fixes as fast as 
> possible. Some software in the cloud are even updated/patched several times 
> per day. We’re not there yet but we’re trying to get closer by reducing from 
> 3 months to 1 month
> * This also means more marketing for the xwiki project since other site relay 
> the new whenever a final version is released
> 
> Proposal Details:
> * 1 month split in: 3 weeks to release a RC + 1 week to release the final 
> version. It’s very important to keep the RC as a meeting point and ensuring 
> all is going to be ready on time for the final release (jiras are closed or 
> moved to the next release, CI is passing, documentation and RN are ready, 
> etc).
> * Split large features into smaller chunks. It doesn’t matter if some code is 
> released but unused for example (provided the build is passing). For larger 
> refactoring that absolutely cannot be split into 3 weeks chunks (I’m not sure 
> that really exists) then we can use branches (and create a CI job to ensure 
> integration).
> * Less need for bugfix releases of stable versions. For LTS it’s still 
> required though.
> * Note that this 1 month release strategy will not generate more releases 
> (and thus more work) over the year since we’re already releasing every 2-3 
> weeks ATM (milestones, RCs, et)
> * Version Naming: from N.0 to N.10 where N is the cycle name. The reason for 
> 11 releases and not 12 is to account for slippages + potential bugfix release 
> at the end of the cycle for stabilization + holidays. We might even be able 
> to do only 10 releases and not 11 but I’m suggesting we try with 11 for now.
> 
> When:
> * I’m proposing to start this process with the 8.4 release (starting on the 
> 10th of October). Since that version is already supposed to be a 
> stabilization release (and thus a short 1 month release) it’s not going to 
> change anything. We should also do bugfix releases after 8.4 is releases: 
> 8.4.1, 8.4.2, etc till the end of the year
> * Then starting 9.0 we really start doing 1 month releases.
> 
> WDYT?
> 
> Here’s my +1 to try this.
> 
> Thanks
> -Vincent
> 
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Change the release cycle to 1 month

[Guillaume Delhumeau]

+1

2016-09-15 11:18 GMT+02:00 Vincent Massol :

> Hi devs,
>
> Executive summary:
> * Replace our 3 month release cycle by a 1 month release cycle.
>
> Needs and advantages:
> * Be able to get our changes faster to our users. Importantly, bugfixes
> are released faster to users. Note: it’s not because we release faster that
> our users have to upgrade as fast. They can skip some versions if they
> want/need.
> * Be able to get more feedback more quickly from users. Right now, most
> (if not all) of our users are testing only final versions. They’re not
> testing milestones or RCs and thus we usually only know about problems
> after the final has been released and we incorporate the change in the next
> one (to be released 3 months later) or we have to do a bugfix release.
> * Get closer to cloud needs. Nowadays, could offerings happen more and
> more and operating a cloud means bringing improvements and fixes as fast as
> possible. Some software in the cloud are even updated/patched several times
> per day. We’re not there yet but we’re trying to get closer by reducing
> from 3 months to 1 month
> * This also means more marketing for the xwiki project since other site
> relay the new whenever a final version is released
>
> Proposal Details:
> * 1 month split in: 3 weeks to release a RC + 1 week to release the final
> version. It’s very important to keep the RC as a meeting point and ensuring
> all is going to be ready on time for the final release (jiras are closed or
> moved to the next release, CI is passing, documentation and RN are ready,
> etc).
> * Split large features into smaller chunks. It doesn’t matter if some code
> is released but unused for example (provided the build is passing). For
> larger refactoring that absolutely cannot be split into 3 weeks chunks (I’m
> not sure that really exists) then we can use branches (and create a CI job
> to ensure integration).
> * Less need for bugfix releases of stable versions. For LTS it’s still
> required though.
> * Note that this 1 month release strategy will not generate more releases
> (and thus more work) over the year since we’re already releasing every 2-3
> weeks ATM (milestones, RCs, et)
> * Version Naming: from N.0 to N.10 where N is the cycle name. The reason
> for 11 releases and not 12 is to account for slippages + potential bugfix
> release at the end of the cycle for stabilization + holidays. We might even
> be able to do only 10 releases and not 11 but I’m suggesting we try with 11
> for now.
>
> When:
> * I’m proposing to start this process with the 8.4 release (starting on
> the 10th of October). Since that version is already supposed to be a
> stabilization release (and thus a short 1 month release) it’s not going to
> change anything. We should also do bugfix releases after 8.4 is releases:
> 8.4.1, 8.4.2, etc till the end of the year
> * Then starting 9.0 we really start doing 1 month releases.
>
> WDYT?
>
> Here’s my +1 to try this.
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Change the release cycle to 1 month

[Vincent Massol]

> On 15 Sep 2016, at 13:23, Ecaterina Moraru (Valica)  wrote:
> 
> On Thu, Sep 15, 2016 at 1:15 PM, Vincent Massol  wrote:
> 
>> 
>>> On 15 Sep 2016, at 11:40, Ecaterina Moraru (Valica) 
>> wrote:
>>> 
>>> +0 I'm not thrilled since:
>>> - it will put pressure on the RMs (there are several steps additional
>> done
>>> for final releases + the ci needs to be shiny perfect +
>> 
>> Could you be more specific? I don’t see any change for the RMs.
>> 
>>> increases the
>>> number of jobs and branches for versions + branches for partial
>> features);
>> 
>> Actually, as I’ve mentioned in my mail, it should decrease slightly the
>> number of branches/jobs since we’ll have less bugfix releases for stable
>> versions. Or keep it similar. But I don’t see an increase.
>> 
>>> - in theory all the releases should be tested fully (before we had a
>> buffer
>>> to catch bugs between Ms + more time for the community to test the
>>> releases) and
>> 
>> Yes that’s part of the rational I put: increase the testers and use more
>> the community to test.
>> 
>> Our scope has been increasing over the years (more features, more
>> extensions). It’s important to use more and more the community to help us.
>> 
>>> - the roadmap items planning might need more issues/bureaucracy.
>> 
>> Possibly a bit. But the way I view this is that we’ll continue to do
>> roadmaps every 3 months or so for the coming 3 releases and do the steering
>> every month in case we want to change it slightly.
>> 
>>> Also users might be confused about the 'quality'/frequency of releases
>> and
>>> they might adopt strategies like installing even/odd release version or
>>> just bugfix releases. So I'm not sure this will fix use case in terms of
>>> users feedback.
>> 
>> It does. If you’re an existing user and you’re upgrading, say every 6
>> months, it won’t change anything ofc.
>> 
>> But if you’re a new user, you’ll be able to use the latest released
>> version. And report feedback, bugs, ideas, etc. You won’t start on a 3
>> months old release.
>> 
>>> It's just a feeling I have and I'm a bit worried since our community is
>>> small, but maybe I'm just resistant to change. I'm willing to try though.
>> 
>> You do look a bit resistant to change :)
>> 
>> But that’s fine. It’s good to have someone playing the devil’s advocate.
>> 
>> However, I haven’t seen any real cause for being worried so far.
>> 
>> Honestly it's almost is a non event and doesn’t change much IMO. It just
>> means removing the suffix “milestone” from our releases ;)
>> 
>>> I would prefer 10 releases N.0 to N.9 (just for 'esthetic' reasons).
>> Also I
>>> would have prefer to start this new version/release scheme for the 9.x
>>> cycle, instead of butchering the 8.4+ stabilization releases (for
>>> 'consistency' reasons).
>> 
>> Could you explain what you mean by butchering? Could you also explain what
>> is not clear in:
>> “[….]Since that version is already supposed to be a stabilization release
>> (and thus a short 1 month release) it’s not going to change anything.[…]"
>> 
> 
> By butchering I meant having 8.4, 8.5, 8.6, 8.7, etc. and having to explain
> the users that for the 8.x cycle the versioning strategy changed meanwhile
> and 8.7 is equivalent to 7.4 final. But the thing is that I forgot that
> 8.4+ were shorter releases, so I guess you are right: it doesn't change a
> thing. By the end of the year we should have just 8.4 and 8.5.

Actually we’ve decided a while back to no longer have N.5 releases because we 
don’t have enough time at the end and we usually have to carry the remaining 
stabilization/polishing work in the next year.

So the idea is to have 8.4 till around mid November (i.e. 1 month) and then to 
do bug fix releases of 8.4 every 2 weeks, i.e. 8.4.1, 8.4.2, etc.

And then on Jan 2nd, start 9.0.

Thanks
-Vincent

> Thanks for the explanations,
> Caty
> 
> 
>> 
>> So to remind you, the last stabilization release is already meant to be 1
>> month (we’ve been doing this for some time already, even doing it for the
>> last 2 releases in the past when we had a N.5 release), so as I said, it
>> doesn’t change anything.
>> 
>> So in practice I could have omitted this part since it’s the same as
>> saying we start only in 9.0 but I wanted to put us in the spirit of the new
>> strategy ASAP.
>> 
>> Thanks
>> -Vincent
>> 
>>> Thanks,
>>> Caty
>>> 
>>> 
>>> On Thu, Sep 15, 2016 at 12:18 PM, Vincent Massol 
>> wrote:
>>> 
 Hi devs,
 
 Executive summary:
 * Replace our 3 month release cycle by a 1 month release cycle.
 
 Needs and advantages:
 * Be able to get our changes faster to our users. Importantly, bugfixes
 are released faster to users. Note: it’s not because we release faster
>> that
 our users have to upgrade as fast. They can skip some versions if they
 want/need.
 * Be able to get more feedback more quickly from users. Right now, most
 

Re: [xwiki-devs] [VOTE] Change the release cycle to 1 month

[Ecaterina Moraru (Valica)]

On Thu, Sep 15, 2016 at 1:15 PM, Vincent Massol  wrote:

>
> > On 15 Sep 2016, at 11:40, Ecaterina Moraru (Valica) 
> wrote:
> >
> > +0 I'm not thrilled since:
> > - it will put pressure on the RMs (there are several steps additional
> done
> > for final releases + the ci needs to be shiny perfect +
>
> Could you be more specific? I don’t see any change for the RMs.
>
> > increases the
> > number of jobs and branches for versions + branches for partial
> features);
>
> Actually, as I’ve mentioned in my mail, it should decrease slightly the
> number of branches/jobs since we’ll have less bugfix releases for stable
> versions. Or keep it similar. But I don’t see an increase.
>
> > - in theory all the releases should be tested fully (before we had a
> buffer
> > to catch bugs between Ms + more time for the community to test the
> > releases) and
>
> Yes that’s part of the rational I put: increase the testers and use more
> the community to test.
>
> Our scope has been increasing over the years (more features, more
> extensions). It’s important to use more and more the community to help us.
>
> > - the roadmap items planning might need more issues/bureaucracy.
>
> Possibly a bit. But the way I view this is that we’ll continue to do
> roadmaps every 3 months or so for the coming 3 releases and do the steering
> every month in case we want to change it slightly.
>
> > Also users might be confused about the 'quality'/frequency of releases
> and
> > they might adopt strategies like installing even/odd release version or
> > just bugfix releases. So I'm not sure this will fix use case in terms of
> > users feedback.
>
> It does. If you’re an existing user and you’re upgrading, say every 6
> months, it won’t change anything ofc.
>
> But if you’re a new user, you’ll be able to use the latest released
> version. And report feedback, bugs, ideas, etc. You won’t start on a 3
> months old release.
>
> > It's just a feeling I have and I'm a bit worried since our community is
> > small, but maybe I'm just resistant to change. I'm willing to try though.
>
> You do look a bit resistant to change :)
>
> But that’s fine. It’s good to have someone playing the devil’s advocate.
>
> However, I haven’t seen any real cause for being worried so far.
>
> Honestly it's almost is a non event and doesn’t change much IMO. It just
> means removing the suffix “milestone” from our releases ;)
>
> > I would prefer 10 releases N.0 to N.9 (just for 'esthetic' reasons).
> Also I
> > would have prefer to start this new version/release scheme for the 9.x
> > cycle, instead of butchering the 8.4+ stabilization releases (for
> > 'consistency' reasons).
>
> Could you explain what you mean by butchering? Could you also explain what
> is not clear in:
> “[….]Since that version is already supposed to be a stabilization release
> (and thus a short 1 month release) it’s not going to change anything.[…]"
>

By butchering I meant having 8.4, 8.5, 8.6, 8.7, etc. and having to explain
the users that for the 8.x cycle the versioning strategy changed meanwhile
and 8.7 is equivalent to 7.4 final. But the thing is that I forgot that
8.4+ were shorter releases, so I guess you are right: it doesn't change a
thing. By the end of the year we should have just 8.4 and 8.5.

Thanks for the explanations,
Caty


>
> So to remind you, the last stabilization release is already meant to be 1
> month (we’ve been doing this for some time already, even doing it for the
> last 2 releases in the past when we had a N.5 release), so as I said, it
> doesn’t change anything.
>
> So in practice I could have omitted this part since it’s the same as
> saying we start only in 9.0 but I wanted to put us in the spirit of the new
> strategy ASAP.
>
> Thanks
> -Vincent
>
> > Thanks,
> > Caty
> >
> >
> > On Thu, Sep 15, 2016 at 12:18 PM, Vincent Massol 
> wrote:
> >
> >> Hi devs,
> >>
> >> Executive summary:
> >> * Replace our 3 month release cycle by a 1 month release cycle.
> >>
> >> Needs and advantages:
> >> * Be able to get our changes faster to our users. Importantly, bugfixes
> >> are released faster to users. Note: it’s not because we release faster
> that
> >> our users have to upgrade as fast. They can skip some versions if they
> >> want/need.
> >> * Be able to get more feedback more quickly from users. Right now, most
> >> (if not all) of our users are testing only final versions. They’re not
> >> testing milestones or RCs and thus we usually only know about problems
> >> after the final has been released and we incorporate the change in the
> next
> >> one (to be released 3 months later) or we have to do a bugfix release.
> >> * Get closer to cloud needs. Nowadays, could offerings happen more and
> >> more and operating a cloud means bringing improvements and fixes as
> fast as
> >> possible. Some software in the cloud are even updated/patched several
> times
> >> per day. We’re not there yet but we’re trying to get 

Re: [xwiki-devs] [VOTE] Change the release cycle to 1 month

[Vincent Massol]

> On 15 Sep 2016, at 11:40, Ecaterina Moraru (Valica)  wrote:
> 
> +0 I'm not thrilled since:
> - it will put pressure on the RMs (there are several steps additional done
> for final releases + the ci needs to be shiny perfect +

Could you be more specific? I don’t see any change for the RMs.

> increases the
> number of jobs and branches for versions + branches for partial features);

Actually, as I’ve mentioned in my mail, it should decrease slightly the number 
of branches/jobs since we’ll have less bugfix releases for stable versions. Or 
keep it similar. But I don’t see an increase.

> - in theory all the releases should be tested fully (before we had a buffer
> to catch bugs between Ms + more time for the community to test the
> releases) and

Yes that’s part of the rational I put: increase the testers and use more the 
community to test.

Our scope has been increasing over the years (more features, more extensions). 
It’s important to use more and more the community to help us.

> - the roadmap items planning might need more issues/bureaucracy.

Possibly a bit. But the way I view this is that we’ll continue to do roadmaps 
every 3 months or so for the coming 3 releases and do the steering every month 
in case we want to change it slightly.

> Also users might be confused about the 'quality'/frequency of releases and
> they might adopt strategies like installing even/odd release version or
> just bugfix releases. So I'm not sure this will fix use case in terms of
> users feedback.

It does. If you’re an existing user and you’re upgrading, say every 6 months, 
it won’t change anything ofc.

But if you’re a new user, you’ll be able to use the latest released version. 
And report feedback, bugs, ideas, etc. You won’t start on a 3 months old 
release.

> It's just a feeling I have and I'm a bit worried since our community is
> small, but maybe I'm just resistant to change. I'm willing to try though.

You do look a bit resistant to change :)

But that’s fine. It’s good to have someone playing the devil’s advocate. 

However, I haven’t seen any real cause for being worried so far.

Honestly it's almost is a non event and doesn’t change much IMO. It just means 
removing the suffix “milestone” from our releases ;)

> I would prefer 10 releases N.0 to N.9 (just for 'esthetic' reasons). Also I
> would have prefer to start this new version/release scheme for the 9.x
> cycle, instead of butchering the 8.4+ stabilization releases (for
> 'consistency' reasons).

Could you explain what you mean by butchering? Could you also explain what is 
not clear in:
“[….]Since that version is already supposed to be a stabilization release (and 
thus a short 1 month release) it’s not going to change anything.[…]"

So to remind you, the last stabilization release is already meant to be 1 month 
(we’ve been doing this for some time already, even doing it for the last 2 
releases in the past when we had a N.5 release), so as I said, it doesn’t 
change anything.

So in practice I could have omitted this part since it’s the same as saying we 
start only in 9.0 but I wanted to put us in the spirit of the new strategy ASAP.

Thanks
-Vincent

> Thanks,
> Caty
> 
> 
> On Thu, Sep 15, 2016 at 12:18 PM, Vincent Massol  wrote:
> 
>> Hi devs,
>> 
>> Executive summary:
>> * Replace our 3 month release cycle by a 1 month release cycle.
>> 
>> Needs and advantages:
>> * Be able to get our changes faster to our users. Importantly, bugfixes
>> are released faster to users. Note: it’s not because we release faster that
>> our users have to upgrade as fast. They can skip some versions if they
>> want/need.
>> * Be able to get more feedback more quickly from users. Right now, most
>> (if not all) of our users are testing only final versions. They’re not
>> testing milestones or RCs and thus we usually only know about problems
>> after the final has been released and we incorporate the change in the next
>> one (to be released 3 months later) or we have to do a bugfix release.
>> * Get closer to cloud needs. Nowadays, could offerings happen more and
>> more and operating a cloud means bringing improvements and fixes as fast as
>> possible. Some software in the cloud are even updated/patched several times
>> per day. We’re not there yet but we’re trying to get closer by reducing
>> from 3 months to 1 month
>> * This also means more marketing for the xwiki project since other site
>> relay the new whenever a final version is released
>> 
>> Proposal Details:
>> * 1 month split in: 3 weeks to release a RC + 1 week to release the final
>> version. It’s very important to keep the RC as a meeting point and ensuring
>> all is going to be ready on time for the final release (jiras are closed or
>> moved to the next release, CI is passing, documentation and RN are ready,
>> etc).
>> * Split large features into smaller chunks. It doesn’t matter if some code
>> is released but unused for example (provided the build is 

Re: [xwiki-devs] [VOTE] Change the release cycle to 1 month

[Thomas Mortagne]

On Thu, Sep 15, 2016 at 11:47 AM, Ecaterina Moraru (Valica)
 wrote:
> Also the design for our Download page might not be optimal with this
> change. Users will have to go more to the Other versions if they will be
> 'recommended' a particular version (just like I said if they will adopt
> some odd/even or  divisibility by 5 rule, etc).
>
> Thanks,
> Caty
>
> On Thu, Sep 15, 2016 at 12:40 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
>
>> +0 I'm not thrilled since:
>> - it will put pressure on the RMs (there are several steps additional done
>> for final releases + the ci needs to be shiny perfect + increases the
>> number of jobs and branches for versions + branches for partial features);
>> - in theory all the releases should be tested fully (before we had a
>> buffer to catch bugs between Ms + more time for the community to test the
>> releases) and
>> - the roadmap items planning might need more issues/bureaucracy.
>>


>> Also users might be confused about the 'quality'/frequency of releases and
>> they might adopt strategies like installing even/odd release version or
>> just bugfix releases. So I'm not sure this will fix use case in terms of
>> users feedback.

We still have LTS for this. Like before users want to be safe will install LTS.

>>
>> It's just a feeling I have and I'm a bit worried since our community is
>> small, but maybe I'm just resistant to change. I'm willing to try though.
>>
>> I would prefer 10 releases N.0 to N.9 (just for 'esthetic' reasons). Also
>> I would have prefer to start this new version/release scheme for the 9.x
>> cycle, instead of butchering the 8.4+ stabilization releases (for
>> 'consistency' reasons).
>>
>> Thanks,
>> Caty
>>
>>
>> On Thu, Sep 15, 2016 at 12:18 PM, Vincent Massol 
>> wrote:
>>
>>> Hi devs,
>>>
>>> Executive summary:
>>> * Replace our 3 month release cycle by a 1 month release cycle.
>>>
>>> Needs and advantages:
>>> * Be able to get our changes faster to our users. Importantly, bugfixes
>>> are released faster to users. Note: it’s not because we release faster that
>>> our users have to upgrade as fast. They can skip some versions if they
>>> want/need.
>>> * Be able to get more feedback more quickly from users. Right now, most
>>> (if not all) of our users are testing only final versions. They’re not
>>> testing milestones or RCs and thus we usually only know about problems
>>> after the final has been released and we incorporate the change in the next
>>> one (to be released 3 months later) or we have to do a bugfix release.
>>> * Get closer to cloud needs. Nowadays, could offerings happen more and
>>> more and operating a cloud means bringing improvements and fixes as fast as
>>> possible. Some software in the cloud are even updated/patched several times
>>> per day. We’re not there yet but we’re trying to get closer by reducing
>>> from 3 months to 1 month
>>> * This also means more marketing for the xwiki project since other site
>>> relay the new whenever a final version is released
>>>
>>> Proposal Details:
>>> * 1 month split in: 3 weeks to release a RC + 1 week to release the final
>>> version. It’s very important to keep the RC as a meeting point and ensuring
>>> all is going to be ready on time for the final release (jiras are closed or
>>> moved to the next release, CI is passing, documentation and RN are ready,
>>> etc).
>>> * Split large features into smaller chunks. It doesn’t matter if some
>>> code is released but unused for example (provided the build is passing).
>>> For larger refactoring that absolutely cannot be split into 3 weeks chunks
>>> (I’m not sure that really exists) then we can use branches (and create a CI
>>> job to ensure integration).
>>> * Less need for bugfix releases of stable versions. For LTS it’s still
>>> required though.
>>> * Note that this 1 month release strategy will not generate more releases
>>> (and thus more work) over the year since we’re already releasing every 2-3
>>> weeks ATM (milestones, RCs, et)
>>> * Version Naming: from N.0 to N.10 where N is the cycle name. The reason
>>> for 11 releases and not 12 is to account for slippages + potential bugfix
>>> release at the end of the cycle for stabilization + holidays. We might even
>>> be able to do only 10 releases and not 11 but I’m suggesting we try with 11
>>> for now.
>>>
>>> When:
>>> * I’m proposing to start this process with the 8.4 release (starting on
>>> the 10th of October). Since that version is already supposed to be a
>>> stabilization release (and thus a short 1 month release) it’s not going to
>>> change anything. We should also do bugfix releases after 8.4 is releases:
>>> 8.4.1, 8.4.2, etc till the end of the year
>>> * Then starting 9.0 we really start doing 1 month releases.
>>>
>>> WDYT?
>>>
>>> Here’s my +1 to try this.

+1

>>>
>>> Thanks
>>> -Vincent
>>>
>>> ___
>>> devs mailing list
>>> devs@xwiki.org
>>> 

Re: [xwiki-devs] [VOTE] Change the release cycle to 1 month

[Marius Dumitru Florea]

+1 Let's try.

Thanks,
Marius

On Thu, Sep 15, 2016 at 12:18 PM, Vincent Massol  wrote:

> Hi devs,
>
> Executive summary:
> * Replace our 3 month release cycle by a 1 month release cycle.
>
> Needs and advantages:
> * Be able to get our changes faster to our users. Importantly, bugfixes
> are released faster to users. Note: it’s not because we release faster that
> our users have to upgrade as fast. They can skip some versions if they
> want/need.
> * Be able to get more feedback more quickly from users. Right now, most
> (if not all) of our users are testing only final versions. They’re not
> testing milestones or RCs and thus we usually only know about problems
> after the final has been released and we incorporate the change in the next
> one (to be released 3 months later) or we have to do a bugfix release.
> * Get closer to cloud needs. Nowadays, could offerings happen more and
> more and operating a cloud means bringing improvements and fixes as fast as
> possible. Some software in the cloud are even updated/patched several times
> per day. We’re not there yet but we’re trying to get closer by reducing
> from 3 months to 1 month
> * This also means more marketing for the xwiki project since other site
> relay the new whenever a final version is released
>
> Proposal Details:
> * 1 month split in: 3 weeks to release a RC + 1 week to release the final
> version. It’s very important to keep the RC as a meeting point and ensuring
> all is going to be ready on time for the final release (jiras are closed or
> moved to the next release, CI is passing, documentation and RN are ready,
> etc).
> * Split large features into smaller chunks. It doesn’t matter if some code
> is released but unused for example (provided the build is passing). For
> larger refactoring that absolutely cannot be split into 3 weeks chunks (I’m
> not sure that really exists) then we can use branches (and create a CI job
> to ensure integration).
> * Less need for bugfix releases of stable versions. For LTS it’s still
> required though.
> * Note that this 1 month release strategy will not generate more releases
> (and thus more work) over the year since we’re already releasing every 2-3
> weeks ATM (milestones, RCs, et)
> * Version Naming: from N.0 to N.10 where N is the cycle name. The reason
> for 11 releases and not 12 is to account for slippages + potential bugfix
> release at the end of the cycle for stabilization + holidays. We might even
> be able to do only 10 releases and not 11 but I’m suggesting we try with 11
> for now.
>
> When:
> * I’m proposing to start this process with the 8.4 release (starting on
> the 10th of October). Since that version is already supposed to be a
> stabilization release (and thus a short 1 month release) it’s not going to
> change anything. We should also do bugfix releases after 8.4 is releases:
> 8.4.1, 8.4.2, etc till the end of the year
> * Then starting 9.0 we really start doing 1 month releases.
>
> WDYT?
>
> Here’s my +1 to try this.
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Change the release cycle to 1 month

[Ecaterina Moraru (Valica)]

Also the design for our Download page might not be optimal with this
change. Users will have to go more to the Other versions if they will be
'recommended' a particular version (just like I said if they will adopt
some odd/even or  divisibility by 5 rule, etc).

Thanks,
Caty

On Thu, Sep 15, 2016 at 12:40 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> +0 I'm not thrilled since:
> - it will put pressure on the RMs (there are several steps additional done
> for final releases + the ci needs to be shiny perfect + increases the
> number of jobs and branches for versions + branches for partial features);
> - in theory all the releases should be tested fully (before we had a
> buffer to catch bugs between Ms + more time for the community to test the
> releases) and
> - the roadmap items planning might need more issues/bureaucracy.
>
> Also users might be confused about the 'quality'/frequency of releases and
> they might adopt strategies like installing even/odd release version or
> just bugfix releases. So I'm not sure this will fix use case in terms of
> users feedback.
>
> It's just a feeling I have and I'm a bit worried since our community is
> small, but maybe I'm just resistant to change. I'm willing to try though.
>
> I would prefer 10 releases N.0 to N.9 (just for 'esthetic' reasons). Also
> I would have prefer to start this new version/release scheme for the 9.x
> cycle, instead of butchering the 8.4+ stabilization releases (for
> 'consistency' reasons).
>
> Thanks,
> Caty
>
>
> On Thu, Sep 15, 2016 at 12:18 PM, Vincent Massol 
> wrote:
>
>> Hi devs,
>>
>> Executive summary:
>> * Replace our 3 month release cycle by a 1 month release cycle.
>>
>> Needs and advantages:
>> * Be able to get our changes faster to our users. Importantly, bugfixes
>> are released faster to users. Note: it’s not because we release faster that
>> our users have to upgrade as fast. They can skip some versions if they
>> want/need.
>> * Be able to get more feedback more quickly from users. Right now, most
>> (if not all) of our users are testing only final versions. They’re not
>> testing milestones or RCs and thus we usually only know about problems
>> after the final has been released and we incorporate the change in the next
>> one (to be released 3 months later) or we have to do a bugfix release.
>> * Get closer to cloud needs. Nowadays, could offerings happen more and
>> more and operating a cloud means bringing improvements and fixes as fast as
>> possible. Some software in the cloud are even updated/patched several times
>> per day. We’re not there yet but we’re trying to get closer by reducing
>> from 3 months to 1 month
>> * This also means more marketing for the xwiki project since other site
>> relay the new whenever a final version is released
>>
>> Proposal Details:
>> * 1 month split in: 3 weeks to release a RC + 1 week to release the final
>> version. It’s very important to keep the RC as a meeting point and ensuring
>> all is going to be ready on time for the final release (jiras are closed or
>> moved to the next release, CI is passing, documentation and RN are ready,
>> etc).
>> * Split large features into smaller chunks. It doesn’t matter if some
>> code is released but unused for example (provided the build is passing).
>> For larger refactoring that absolutely cannot be split into 3 weeks chunks
>> (I’m not sure that really exists) then we can use branches (and create a CI
>> job to ensure integration).
>> * Less need for bugfix releases of stable versions. For LTS it’s still
>> required though.
>> * Note that this 1 month release strategy will not generate more releases
>> (and thus more work) over the year since we’re already releasing every 2-3
>> weeks ATM (milestones, RCs, et)
>> * Version Naming: from N.0 to N.10 where N is the cycle name. The reason
>> for 11 releases and not 12 is to account for slippages + potential bugfix
>> release at the end of the cycle for stabilization + holidays. We might even
>> be able to do only 10 releases and not 11 but I’m suggesting we try with 11
>> for now.
>>
>> When:
>> * I’m proposing to start this process with the 8.4 release (starting on
>> the 10th of October). Since that version is already supposed to be a
>> stabilization release (and thus a short 1 month release) it’s not going to
>> change anything. We should also do bugfix releases after 8.4 is releases:
>> 8.4.1, 8.4.2, etc till the end of the year
>> * Then starting 9.0 we really start doing 1 month releases.
>>
>> WDYT?
>>
>> Here’s my +1 to try this.
>>
>> Thanks
>> -Vincent
>>
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Change the release cycle to 1 month

[Ecaterina Moraru (Valica)]

+0 I'm not thrilled since:
- it will put pressure on the RMs (there are several steps additional done
for final releases + the ci needs to be shiny perfect + increases the
number of jobs and branches for versions + branches for partial features);
- in theory all the releases should be tested fully (before we had a buffer
to catch bugs between Ms + more time for the community to test the
releases) and
- the roadmap items planning might need more issues/bureaucracy.

Also users might be confused about the 'quality'/frequency of releases and
they might adopt strategies like installing even/odd release version or
just bugfix releases. So I'm not sure this will fix use case in terms of
users feedback.

It's just a feeling I have and I'm a bit worried since our community is
small, but maybe I'm just resistant to change. I'm willing to try though.

I would prefer 10 releases N.0 to N.9 (just for 'esthetic' reasons). Also I
would have prefer to start this new version/release scheme for the 9.x
cycle, instead of butchering the 8.4+ stabilization releases (for
'consistency' reasons).

Thanks,
Caty


On Thu, Sep 15, 2016 at 12:18 PM, Vincent Massol  wrote:

> Hi devs,
>
> Executive summary:
> * Replace our 3 month release cycle by a 1 month release cycle.
>
> Needs and advantages:
> * Be able to get our changes faster to our users. Importantly, bugfixes
> are released faster to users. Note: it’s not because we release faster that
> our users have to upgrade as fast. They can skip some versions if they
> want/need.
> * Be able to get more feedback more quickly from users. Right now, most
> (if not all) of our users are testing only final versions. They’re not
> testing milestones or RCs and thus we usually only know about problems
> after the final has been released and we incorporate the change in the next
> one (to be released 3 months later) or we have to do a bugfix release.
> * Get closer to cloud needs. Nowadays, could offerings happen more and
> more and operating a cloud means bringing improvements and fixes as fast as
> possible. Some software in the cloud are even updated/patched several times
> per day. We’re not there yet but we’re trying to get closer by reducing
> from 3 months to 1 month
> * This also means more marketing for the xwiki project since other site
> relay the new whenever a final version is released
>
> Proposal Details:
> * 1 month split in: 3 weeks to release a RC + 1 week to release the final
> version. It’s very important to keep the RC as a meeting point and ensuring
> all is going to be ready on time for the final release (jiras are closed or
> moved to the next release, CI is passing, documentation and RN are ready,
> etc).
> * Split large features into smaller chunks. It doesn’t matter if some code
> is released but unused for example (provided the build is passing). For
> larger refactoring that absolutely cannot be split into 3 weeks chunks (I’m
> not sure that really exists) then we can use branches (and create a CI job
> to ensure integration).
> * Less need for bugfix releases of stable versions. For LTS it’s still
> required though.
> * Note that this 1 month release strategy will not generate more releases
> (and thus more work) over the year since we’re already releasing every 2-3
> weeks ATM (milestones, RCs, et)
> * Version Naming: from N.0 to N.10 where N is the cycle name. The reason
> for 11 releases and not 12 is to account for slippages + potential bugfix
> release at the end of the cycle for stabilization + holidays. We might even
> be able to do only 10 releases and not 11 but I’m suggesting we try with 11
> for now.
>
> When:
> * I’m proposing to start this process with the 8.4 release (starting on
> the 10th of October). Since that version is already supposed to be a
> stabilization release (and thus a short 1 month release) it’s not going to
> change anything. We should also do bugfix releases after 8.4 is releases:
> 8.4.1, 8.4.2, etc till the end of the year
> * Then starting 9.0 we really start doing 1 month releases.
>
> WDYT?
>
> Here’s my +1 to try this.
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [VOTE] Change the release cycle to 1 month

[Vincent Massol]

Hi devs,

Executive summary:
* Replace our 3 month release cycle by a 1 month release cycle.

Needs and advantages:
* Be able to get our changes faster to our users. Importantly, bugfixes are 
released faster to users. Note: it’s not because we release faster that our 
users have to upgrade as fast. They can skip some versions if they want/need.
* Be able to get more feedback more quickly from users. Right now, most (if not 
all) of our users are testing only final versions. They’re not testing 
milestones or RCs and thus we usually only know about problems after the final 
has been released and we incorporate the change in the next one (to be released 
3 months later) or we have to do a bugfix release.
* Get closer to cloud needs. Nowadays, could offerings happen more and more and 
operating a cloud means bringing improvements and fixes as fast as possible. 
Some software in the cloud are even updated/patched several times per day. 
We’re not there yet but we’re trying to get closer by reducing from 3 months to 
1 month
* This also means more marketing for the xwiki project since other site relay 
the new whenever a final version is released

Proposal Details:
* 1 month split in: 3 weeks to release a RC + 1 week to release the final 
version. It’s very important to keep the RC as a meeting point and ensuring all 
is going to be ready on time for the final release (jiras are closed or moved 
to the next release, CI is passing, documentation and RN are ready, etc).
* Split large features into smaller chunks. It doesn’t matter if some code is 
released but unused for example (provided the build is passing). For larger 
refactoring that absolutely cannot be split into 3 weeks chunks (I’m not sure 
that really exists) then we can use branches (and create a CI job to ensure 
integration).
* Less need for bugfix releases of stable versions. For LTS it’s still required 
though.
* Note that this 1 month release strategy will not generate more releases (and 
thus more work) over the year since we’re already releasing every 2-3 weeks ATM 
(milestones, RCs, et)
* Version Naming: from N.0 to N.10 where N is the cycle name. The reason for 11 
releases and not 12 is to account for slippages + potential bugfix release at 
the end of the cycle for stabilization + holidays. We might even be able to do 
only 10 releases and not 11 but I’m suggesting we try with 11 for now.

When:
* I’m proposing to start this process with the 8.4 release (starting on the 
10th of October). Since that version is already supposed to be a stabilization 
release (and thus a short 1 month release) it’s not going to change anything. 
We should also do bugfix releases after 8.4 is releases: 8.4.1, 8.4.2, etc till 
the end of the year
* Then starting 9.0 we really start doing 1 month releases.

WDYT?

Here’s my +1 to try this.

Thanks
-Vincent

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs