You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Leif Hedstrom <zw...@apache.org> on 2013/08/11 01:13:13 UTC
[PROPOSAL] New release process
Hi all,
I started a wiki with some ideas on how to streamline and simplify the release process:
https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
I'd like to start the discussion on this, and come to a consensus before next stable release. One key decision here is what the next stable release should be versioned (I'm suggesting we make it v4.0, with no micro version). The alternative is to keep it as we had planned, which would be v3.4.0.
Please discuss, and lets make the updates to that doc as appropriate. Also, if the consensus is to leave the release process as is, we should make that decision as well in the next 2 weeks.
Cheers,
-- leif
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 2:33 PM, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 12.08.2013 22:28, schrieb James Peach:
>> I don't think that a fast release cycle can work without strong compatibility guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The only way everyone will feel comfortable upgrading is if it a no-brainer and always works.
>
> +100
>
> postfix is a perfect example for such a software
>
> if the packager was not a fool you can upgrade postfix
> 2.4 to 2.10 without except breakage in most setups and
> the few incompatible changes a mostly caught with safety-nets
> and/or clearly documented
We have never (afaik) made a stable release that breaks compatibility within that major release. v3.2.5 is 100% compatible to v3.2.0. For the few cases where we did break compatibility (twice so far, not counting the upgrade through our Incubation), they have been documented *). What you are describing with postfix seems pretty much identical to what we have today already.
If I understand James' proposal, there would be no incompatible changes allowed in ATS, unless they also provide a completely automatic upgrade path. That's a pretty fundamental change in how we develop our software, and one that's incredibly difficult to accomplish in my experience.
The idea of keeping master "always releasable is admirable (I like it!) but I think we'd have to change from CTR to RTC (Review Then Commit). Such a change is basically a bylaw change, and would have to be voted on separately. Considering Igor is the only one that regularly reviews commits, I think this would be a real hurdle and put progress in the community at risk.
Ciao,
-- leif
*)
https://cwiki.apache.org/confluence/display/TS/Upgrading+to+v3.2
https://cwiki.apache.org/confluence/display/TS/Upgrading+to+v3.4
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 2:33 PM, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 12.08.2013 22:28, schrieb James Peach:
>> I don't think that a fast release cycle can work without strong compatibility guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The only way everyone will feel comfortable upgrading is if it a no-brainer and always works.
>
> +100
>
> postfix is a perfect example for such a software
>
> if the packager was not a fool you can upgrade postfix
> 2.4 to 2.10 without except breakage in most setups and
> the few incompatible changes a mostly caught with safety-nets
> and/or clearly documented
We have never (afaik) made a stable release that breaks compatibility within that major release. v3.2.5 is 100% compatible to v3.2.0. For the few cases where we did break compatibility (twice so far, not counting the upgrade through our Incubation), they have been documented *). What you are describing with postfix seems pretty much identical to what we have today already.
If I understand James' proposal, there would be no incompatible changes allowed in ATS, unless they also provide a completely automatic upgrade path. That's a pretty fundamental change in how we develop our software, and one that's incredibly difficult to accomplish in my experience.
The idea of keeping master "always releasable is admirable (I like it!) but I think we'd have to change from CTR to RTC (Review Then Commit). Such a change is basically a bylaw change, and would have to be voted on separately. Considering Igor is the only one that regularly reviews commits, I think this would be a real hurdle and put progress in the community at risk.
Ciao,
-- leif
*)
https://cwiki.apache.org/confluence/display/TS/Upgrading+to+v3.2
https://cwiki.apache.org/confluence/display/TS/Upgrading+to+v3.4
Re: [PROPOSAL] New release process
Posted by Reindl Harald <h....@thelounge.net>.
Am 12.08.2013 22:28, schrieb James Peach:
> I don't think that a fast release cycle can work without strong compatibility guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The only way everyone will feel comfortable upgrading is if it a no-brainer and always works.
+100
postfix is a perfect example for such a software
if the packager was not a fool you can upgrade postfix
2.4 to 2.10 without except breakage in most setups and
the few incompatible changes a mostly caught with safety-nets
and/or clearly documented
i started with 2.4 for my first real production server
and until 2.10.1 i can not remeber any broken update
Re: TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
Posted by James Peach <jp...@apache.org>.
On Aug 27, 2013, at 7:29 PM, "Bardwell, William" <wb...@akamai.com> wrote:
> I also think that the current behavior is wrong. I think that TSVConnShutdown(0,1) should be equivalent to shutdown(SHUT_WR) which means that it causes an eof to be read by the other end of the connection. Indeed I am having issues using the VConn from TSHttpConnect() where there is no way to tell it that I am done sending a request such that I get a clear indication when the response is done. Most of the code treats a shutdown properly, but PluginVC::do_io_shutdown() does not seem to do quite the right thing, HttpSM::tunnel_handler_ua() and HttpTunnel::consumer_handler() also treat EOS slightly wrong (they close things up totally), HttpTransact.cc how_to_open_connection() insists on no pending_work which seems wrong...I am working on a fix, but I am not sure if I am there yet.
Are there any small fixes or refactorings that would make the behaviour more consistent? Maybe not a complete fix, but an incremental improvement ...
>
> -William bardwell
> ________________________________________
> From: Alan M. Carroll [amc@network-geographics.com]
> Sent: Saturday, August 17, 2013 10:48 PM
> To: Owens, Steve
> Subject: Re: TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
>
> Monday, August 12, 2013, 5:55:44 PM, you wrote:
>
>> The only API call I am making from within my plugin that could indicate to
>> ATS that we are done with processing is
>
>> TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
>
> That call means "shut down the connection right now", which seems to be precisely the effect you are seeing.
>
> The better thing to do is chain the TS_EVENT_VCONN_WRITE_COMPLETE to the input VIO from which you are getting data. See example/null-transform/null-transform.c:190.
RE: TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
Posted by "Bardwell, William" <wb...@akamai.com>.
I also think that the current behavior is wrong. I think that TSVConnShutdown(0,1) should be equivalent to shutdown(SHUT_WR) which means that it causes an eof to be read by the other end of the connection. Indeed I am having issues using the VConn from TSHttpConnect() where there is no way to tell it that I am done sending a request such that I get a clear indication when the response is done. Most of the code treats a shutdown properly, but PluginVC::do_io_shutdown() does not seem to do quite the right thing, HttpSM::tunnel_handler_ua() and HttpTunnel::consumer_handler() also treat EOS slightly wrong (they close things up totally), HttpTransact.cc how_to_open_connection() insists on no pending_work which seems wrong...I am working on a fix, but I am not sure if I am there yet.
-William bardwell
________________________________________
From: Alan M. Carroll [amc@network-geographics.com]
Sent: Saturday, August 17, 2013 10:48 PM
To: Owens, Steve
Subject: Re: TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
Monday, August 12, 2013, 5:55:44 PM, you wrote:
> The only API call I am making from within my plugin that could indicate to
> ATS that we are done with processing is
> TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
That call means "shut down the connection right now", which seems to be precisely the effect you are seeing.
The better thing to do is chain the TS_EVENT_VCONN_WRITE_COMPLETE to the input VIO from which you are getting data. See example/null-transform/null-transform.c:190.
Re: TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
Posted by "Alan M. Carroll" <am...@network-geographics.com>.
Monday, August 12, 2013, 5:55:44 PM, you wrote:
> The only API call I am making from within my plugin that could indicate to
> ATS that we are done with processing is
> TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
That call means "shut down the connection right now", which seems to be precisely the effect you are seeing.
The better thing to do is chain the TS_EVENT_VCONN_WRITE_COMPLETE to the input VIO from which you are getting data. See example/null-transform/null-transform.c:190.
TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
Posted by "Owens, Steve" <St...@disney.com>.
Hello,
I am not sure if this question should be directed to the users or the dev
discussion group so please advise on proper categorization of this inquiry.
I am trying to debug a transformation plugin that I have developed that
simply prepends and appends a small string to whatever content is being
returned to the client.
About 70% of the time this plugin works as expected and writes the prefix
and suffix and the entire content is delivered to the client.
However about 30% of the time the content is truncated at the client even
though the trace logging indicates that all of the content was written to
the output VIO.
It seems to be a race condition wherein sometimes the transaction is shut
down before ATS delivers all of the content to the client.
The only API call I am making from within my plugin that could indicate to
ATS that we are done with processing is
TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
I am making this call in response to a TS_EVENT_VCONN_WRITE_COMPLETE
subject to the following conditions:
1. I have already written all content that I am ever going to write to the
Output VIO e.g 33993 bytes in total.
2. I have confirmed that the output_vio.nbytes = 33993; output_vio.ndone=
33993.
I do not make the call to
TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1) unless both
conditions are met.
YET, for some reason in about 1/3 of the times the code executes, the
content is truncated and I am observing things in my logs that indicate
that something has shut down the transaction.
My question is what more can I do to ensure that ATS behaves reliably and
delivers the content that I have written to the output vio to the client?
Best Regards,
Steve Owens
TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
Posted by "Owens, Steve" <St...@disney.com>.
Hello,
I am not sure if this question should be directed to the users or the dev
discussion group so please advise on proper categorization of this inquiry.
I am trying to debug a transformation plugin that I have developed that
simply prepends and appends a small string to whatever content is being
returned to the client.
About 70% of the time this plugin works as expected and writes the prefix
and suffix and the entire content is delivered to the client.
However about 30% of the time the content is truncated at the client even
though the trace logging indicates that all of the content was written to
the output VIO.
It seems to be a race condition wherein sometimes the transaction is shut
down before ATS delivers all of the content to the client.
The only API call I am making from within my plugin that could indicate to
ATS that we are done with processing is
TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
I am making this call in response to a TS_EVENT_VCONN_WRITE_COMPLETE
subject to the following conditions:
1. I have already written all content that I am ever going to write to the
Output VIO e.g 33993 bytes in total.
2. I have confirmed that the output_vio.nbytes = 33993; output_vio.ndone=
33993.
I do not make the call to
TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1) unless both
conditions are met.
YET, for some reason in about 1/3 of the times the code executes, the
content is truncated and I am observing things in my logs that indicate
that something has shut down the transaction.
My question is what more can I do to ensure that ATS behaves reliably and
delivers the content that I have written to the output vio to the client?
Best Regards,
Steve Owens
Re: [PROPOSAL] New release process
Posted by James Peach <jp...@apache.org>.
On Aug 12, 2013, at 1:56 PM, Leif Hedstrom <zw...@apache.org> wrote:
> On Aug 12, 2013, at 2:28 PM, James Peach <jp...@apache.org> wrote:
>
>> On Aug 12, 2013, at 12:56 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>>> On Aug 12, 2013, at 1:32 PM, James Peach <jp...@apache.org> wrote:
>>>
>>>>
>>>
>>> I think the fixed dates is a very minor issue in comparison to the compatibility ideas. I personally think it's a step in the wrong direction (the rest of the OpenSource world is moving towards agile methodologies), but I would not oppose fixed release dates if that's the consensus of the community. It certainly does make the release process predictable.
>>
>> I don't think that a fast release cycle can work without strong compatibility guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The only way everyone will feel comfortable upgrading is if it a no-brainer and always works.
>
> Why do they have to be exclusive? The proposal suggested basically:
>
> - <n> number of releases per year, where compatibility is guaranteed. We can make n=4, that's good.
> - Once a year (or whatever, it doesn't specify), we allow to break compatibility.
>
>
> So, it would be safe for people to upgrade through the incremental releases (just as has been the case for all stable releases so far). Once a year, or whatever, we have the option to make an incompatible release. That doesn't mean we *have* to make an incompatible release. We'd bump major version if/when such a release gets made (my suggestions was to aim for no more than 1/ year).
>
> The downside is that it can be up to 1 year before an incompatible change gets into a release. I personally think that's a reasonable compromise, if it can save a humongous amount of headache to try to provide automatic migrations through every release.
Ok, I think that we are saying the same thing then.
>
> Does anyone other than me and James and Reindl have an opinion here? :-)
>
> -- Leif
Re: [PROPOSAL] New release process
Posted by James Peach <jp...@apache.org>.
On Aug 12, 2013, at 1:56 PM, Leif Hedstrom <zw...@apache.org> wrote:
> On Aug 12, 2013, at 2:28 PM, James Peach <jp...@apache.org> wrote:
>
>> On Aug 12, 2013, at 12:56 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>>> On Aug 12, 2013, at 1:32 PM, James Peach <jp...@apache.org> wrote:
>>>
>>>>
>>>
>>> I think the fixed dates is a very minor issue in comparison to the compatibility ideas. I personally think it's a step in the wrong direction (the rest of the OpenSource world is moving towards agile methodologies), but I would not oppose fixed release dates if that's the consensus of the community. It certainly does make the release process predictable.
>>
>> I don't think that a fast release cycle can work without strong compatibility guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The only way everyone will feel comfortable upgrading is if it a no-brainer and always works.
>
> Why do they have to be exclusive? The proposal suggested basically:
>
> - <n> number of releases per year, where compatibility is guaranteed. We can make n=4, that's good.
> - Once a year (or whatever, it doesn't specify), we allow to break compatibility.
>
>
> So, it would be safe for people to upgrade through the incremental releases (just as has been the case for all stable releases so far). Once a year, or whatever, we have the option to make an incompatible release. That doesn't mean we *have* to make an incompatible release. We'd bump major version if/when such a release gets made (my suggestions was to aim for no more than 1/ year).
>
> The downside is that it can be up to 1 year before an incompatible change gets into a release. I personally think that's a reasonable compromise, if it can save a humongous amount of headache to try to provide automatic migrations through every release.
Ok, I think that we are saying the same thing then.
>
> Does anyone other than me and James and Reindl have an opinion here? :-)
>
> -- Leif
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 2:28 PM, James Peach <jp...@apache.org> wrote:
> On Aug 12, 2013, at 12:56 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>> On Aug 12, 2013, at 1:32 PM, James Peach <jp...@apache.org> wrote:
>>
>>>
>>
>> I think the fixed dates is a very minor issue in comparison to the compatibility ideas. I personally think it's a step in the wrong direction (the rest of the OpenSource world is moving towards agile methodologies), but I would not oppose fixed release dates if that's the consensus of the community. It certainly does make the release process predictable.
>
> I don't think that a fast release cycle can work without strong compatibility guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The only way everyone will feel comfortable upgrading is if it a no-brainer and always works.
Why do they have to be exclusive? The proposal suggested basically:
- <n> number of releases per year, where compatibility is guaranteed. We can make n=4, that's good.
- Once a year (or whatever, it doesn't specify), we allow to break compatibility.
So, it would be safe for people to upgrade through the incremental releases (just as has been the case for all stable releases so far). Once a year, or whatever, we have the option to make an incompatible release. That doesn't mean we *have* to make an incompatible release. We'd bump major version if/when such a release gets made (my suggestions was to aim for no more than 1/ year).
The downside is that it can be up to 1 year before an incompatible change gets into a release. I personally think that's a reasonable compromise, if it can save a humongous amount of headache to try to provide automatic migrations through every release.
Does anyone other than me and James and Reindl have an opinion here? :-)
-- Leif
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 2:28 PM, James Peach <jp...@apache.org> wrote:
> On Aug 12, 2013, at 12:56 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>> On Aug 12, 2013, at 1:32 PM, James Peach <jp...@apache.org> wrote:
>>
>>>
>>
>> I think the fixed dates is a very minor issue in comparison to the compatibility ideas. I personally think it's a step in the wrong direction (the rest of the OpenSource world is moving towards agile methodologies), but I would not oppose fixed release dates if that's the consensus of the community. It certainly does make the release process predictable.
>
> I don't think that a fast release cycle can work without strong compatibility guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The only way everyone will feel comfortable upgrading is if it a no-brainer and always works.
Why do they have to be exclusive? The proposal suggested basically:
- <n> number of releases per year, where compatibility is guaranteed. We can make n=4, that's good.
- Once a year (or whatever, it doesn't specify), we allow to break compatibility.
So, it would be safe for people to upgrade through the incremental releases (just as has been the case for all stable releases so far). Once a year, or whatever, we have the option to make an incompatible release. That doesn't mean we *have* to make an incompatible release. We'd bump major version if/when such a release gets made (my suggestions was to aim for no more than 1/ year).
The downside is that it can be up to 1 year before an incompatible change gets into a release. I personally think that's a reasonable compromise, if it can save a humongous amount of headache to try to provide automatic migrations through every release.
Does anyone other than me and James and Reindl have an opinion here? :-)
-- Leif
Re: [PROPOSAL] New release process
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> On Aug 12, 2013, at 3:30 PM, Igor Galić <i....@brainsware.org> wrote:
>
> >
> >> I don't think that a fast release cycle can work without strong
> >> compatibility
> >> guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The
> >> only way everyone will feel comfortable upgrading is if it a no-brainer
> >> and always works.
> >
> > this ^
>
> I'm not sure how we've ended up in this discussion, the above is a given, has
> always been, always will be, and was never disputed.
>
> 1) We have never, ever broken compatibility within a major release. At least
> not intentionally, I think we reverted one such change once?
>
> 2) The Wiki proposal as it was written would never, ever allow you to break
> compatibility within the major release.
I am fully aware of these things. I have merely singled out what
James said — quoting him out of context — because I liked what he
said *generally* - sorry Did not mean to cause Internet Drama!
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 3:30 PM, Igor Galić <i....@brainsware.org> wrote:
>
>> I don't think that a fast release cycle can work without strong compatibility
>> guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The
>> only way everyone will feel comfortable upgrading is if it a no-brainer and
>> always works.
>
> this ^
I'm not sure how we've ended up in this discussion, the above is a given, has always been, always will be, and was never disputed.
1) We have never, ever broken compatibility within a major release. At least not intentionally, I think we reverted one such change once?
2) The Wiki proposal as it was written would never, ever allow you to break compatibility within the major release.
This was always understood, and nothing is changing here.
What the two proposal are about (as far as I can tell) is how to deal with incompatible changes. My proposal was:
"All incompatible changes can only be committed on the next major release branch, say 5.x. Master is always backwards compatible until next major release."
Whereas James's proposal says:
"Incompatible changes are allowed on Master at any time, but *only* if they are accompanied with code that allows for a seamless and automatic upgrade path."
I'm not sure how the second proposal would deal with a situation where it's not possible to provide such an automatic upgrade path, maybe it never happens :).
Cheers,
-- Leif
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 3:30 PM, Igor Galić <i....@brainsware.org> wrote:
>
>> I don't think that a fast release cycle can work without strong compatibility
>> guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The
>> only way everyone will feel comfortable upgrading is if it a no-brainer and
>> always works.
>
> this ^
I'm not sure how we've ended up in this discussion, the above is a given, has always been, always will be, and was never disputed.
1) We have never, ever broken compatibility within a major release. At least not intentionally, I think we reverted one such change once?
2) The Wiki proposal as it was written would never, ever allow you to break compatibility within the major release.
This was always understood, and nothing is changing here.
What the two proposal are about (as far as I can tell) is how to deal with incompatible changes. My proposal was:
"All incompatible changes can only be committed on the next major release branch, say 5.x. Master is always backwards compatible until next major release."
Whereas James's proposal says:
"Incompatible changes are allowed on Master at any time, but *only* if they are accompanied with code that allows for a seamless and automatic upgrade path."
I'm not sure how the second proposal would deal with a situation where it's not possible to provide such an automatic upgrade path, maybe it never happens :).
Cheers,
-- Leif
Re: [PROPOSAL] New release process
Posted by Igor Galić <i....@brainsware.org>.
> I don't think that a fast release cycle can work without strong compatibility
> guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The
> only way everyone will feel comfortable upgrading is if it a no-brainer and
> always works.
this ^
> J
>
>
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [PROPOSAL] New release process
Posted by James Peach <jp...@apache.org>.
On Aug 12, 2013, at 12:56 PM, Leif Hedstrom <zw...@apache.org> wrote:
> On Aug 12, 2013, at 1:32 PM, James Peach <jp...@apache.org> wrote:
>
>> On Aug 12, 2013, at 12:22 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>> Yes. The goal here is to make the release reliable and predictable so that upgrading is not a scary experience or a lot of work.
>>
>>>
>>> Also, how do we deal with incompatibility changes?
>>
>> Configurations and data formats should be automatically upgraded. Everything would need to be release noted thoroughly.
>
> Wow, that's a humongous pain in the ass to deal with. I've done this before (Mozilla) and it truly sucks big time to have to deal with this :-/.
>
> Particularly dealing with live upgrading of the cache would be a monumental task, and *incredibly* risky.
>
> I can right now say I'm hugely -1 on this idea. To put it bluntly, I think we'd kill ourselves and the project if we tried. ;)
>
>
>>
>>> Or are you proposing that we from now on, never make anything incompatible? Incompatible he
>>> * An API needs to be deprecated (and removed) in order to fix / change something significant. For example, the new cache key proposal comes to mind.
>>
>> Mark as deprecated, then remove once the support window has passed.
>
> But I'm missing something then. If there's a support window, you are allowing incompatible changes? What does the support window define? "If you are running a version older then <n> months, we'll not support you upgrading to this version" ?
Well, we can't support every release forever, so we could say the that after 1 year, deprecated APIs get removed.
>>> * New configuration file format(s). [This might be possible to make compatible, by preserving all old config formats as well as the new ones].
>>
>> Automatic upgrade tools.
>
> These upgrade tools runs as part of starting traffic_server every time you start it ? Meaning, I deploy my old configs, and a new binary, and suddenly the configs in the /etc/ directory are modified for me? That seems like a non-starter already, considering that deployment state is not the same as runtime state.
>
> If you mean providing tools that upgrades my configs, I make new config packages, and push that in conjunction with a binary update, then that's not compatible, right ? Compatible here would imply I can replace the binaries only, and things will just magically work.
>
>
>>
>>> * Remove the incompatibility branch and release cycle. There's only master and the release branch.
>>> * Define hard release dates (say, 9/1/2013, 12/1/2013, 3/1/2013 etc.)
>>>
>>> Does that sum it up ?
>>
>> Pretty much. I think the only way a rapid release cycle can work is if there is confidence that upgrading never breaks. IMHO, this is a good thing to have independent of the release process, but it's not necessarily easy to achieve. I think that fixed release dates focus the mind and make the process more predictable.
>
> I agree 100% that having backward compatibility can be nice. I think it opens up an enormous can of worm, that will make our project impossible to work with (but, that's just my biased, unscientific opinion, please prove me wrong). This is why the proposal had the additional release cycle for incompatible changes, with a longer release train (say, 1 / year).
>
> I think the fixed dates is a very minor issue in comparison to the compatibility ideas. I personally think it's a step in the wrong direction (the rest of the OpenSource world is moving towards agile methodologies), but I would not oppose fixed release dates if that's the consensus of the community. It certainly does make the release process predictable.
I don't think that a fast release cycle can work without strong compatibility guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The only way everyone will feel comfortable upgrading is if it a no-brainer and always works.
J
Re: [PROPOSAL] New release process
Posted by James Peach <jp...@apache.org>.
On Aug 12, 2013, at 12:56 PM, Leif Hedstrom <zw...@apache.org> wrote:
> On Aug 12, 2013, at 1:32 PM, James Peach <jp...@apache.org> wrote:
>
>> On Aug 12, 2013, at 12:22 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>> Yes. The goal here is to make the release reliable and predictable so that upgrading is not a scary experience or a lot of work.
>>
>>>
>>> Also, how do we deal with incompatibility changes?
>>
>> Configurations and data formats should be automatically upgraded. Everything would need to be release noted thoroughly.
>
> Wow, that's a humongous pain in the ass to deal with. I've done this before (Mozilla) and it truly sucks big time to have to deal with this :-/.
>
> Particularly dealing with live upgrading of the cache would be a monumental task, and *incredibly* risky.
>
> I can right now say I'm hugely -1 on this idea. To put it bluntly, I think we'd kill ourselves and the project if we tried. ;)
>
>
>>
>>> Or are you proposing that we from now on, never make anything incompatible? Incompatible he
>>> * An API needs to be deprecated (and removed) in order to fix / change something significant. For example, the new cache key proposal comes to mind.
>>
>> Mark as deprecated, then remove once the support window has passed.
>
> But I'm missing something then. If there's a support window, you are allowing incompatible changes? What does the support window define? "If you are running a version older then <n> months, we'll not support you upgrading to this version" ?
Well, we can't support every release forever, so we could say the that after 1 year, deprecated APIs get removed.
>>> * New configuration file format(s). [This might be possible to make compatible, by preserving all old config formats as well as the new ones].
>>
>> Automatic upgrade tools.
>
> These upgrade tools runs as part of starting traffic_server every time you start it ? Meaning, I deploy my old configs, and a new binary, and suddenly the configs in the /etc/ directory are modified for me? That seems like a non-starter already, considering that deployment state is not the same as runtime state.
>
> If you mean providing tools that upgrades my configs, I make new config packages, and push that in conjunction with a binary update, then that's not compatible, right ? Compatible here would imply I can replace the binaries only, and things will just magically work.
>
>
>>
>>> * Remove the incompatibility branch and release cycle. There's only master and the release branch.
>>> * Define hard release dates (say, 9/1/2013, 12/1/2013, 3/1/2013 etc.)
>>>
>>> Does that sum it up ?
>>
>> Pretty much. I think the only way a rapid release cycle can work is if there is confidence that upgrading never breaks. IMHO, this is a good thing to have independent of the release process, but it's not necessarily easy to achieve. I think that fixed release dates focus the mind and make the process more predictable.
>
> I agree 100% that having backward compatibility can be nice. I think it opens up an enormous can of worm, that will make our project impossible to work with (but, that's just my biased, unscientific opinion, please prove me wrong). This is why the proposal had the additional release cycle for incompatible changes, with a longer release train (say, 1 / year).
>
> I think the fixed dates is a very minor issue in comparison to the compatibility ideas. I personally think it's a step in the wrong direction (the rest of the OpenSource world is moving towards agile methodologies), but I would not oppose fixed release dates if that's the consensus of the community. It certainly does make the release process predictable.
I don't think that a fast release cycle can work without strong compatibility guarantee. Who wants to deal with upgrade issues 3 or 4 times a year? The only way everyone will feel comfortable upgrading is if it a no-brainer and always works.
J
Re: [PROPOSAL] New release process
Posted by Reindl Harald <h....@thelounge.net>.
Am 12.08.2013 21:56, schrieb Leif Hedstrom:
> I think the fixed dates is a very minor issue in comparison to the compatibility ideas.
> I personally think it's a step in the wrong direction (the rest of the OpenSource world
> is moving towards agile methodologies)
from the users and admins point of view the agile methodologies are wrong
not in all case sbut in many
for a webbrowser it's more or less fine because the rapid development
of HTML5 and all sorts of client-side tech wired with server-side apps
and this is still hard enough
in case of server-software agile is not that fine because depending
on the whole infrastructure you maintain as admin you need fixed
schedules for planning and not collide 5 critical updates at the same
time - so i am perfectly happy if i know "twice a year there are releases
i need to care about, any update between is a 100% security fix and nothing
else" for the relevant pieces
____________________________
that's why i can live with Fedora in production even if it is not
that dedicated server-distribution - last week i rolled out F18
and my schedule is to rollout F19 in 2014/01/10 what i noted
in my calendar 5 weeks ago
2013/11/01 my workstation and my homeserver are upgraded
2013/11/08 both workstations of our second tech are upgraded
the server packages are still prepared in a testing-VM including ATS 3.3.5
if there are no problems i consider ATS 3.4/4.0 even for F18, if not it
is rolled out in Jannuary
in the meantime the two people responsible for software-development
and maintainance are on F19/MariaDB/PHP5.5 for regular work
____________________________
until 2014/01 i can be sure there is not coming a incompatible
update except them i want to roll out for internal reasons
this is how you survive a leading-edge distribution with relative high
upgrade pressures over the year on around 25 machines, if you can
expect every random day a bigger update of one of the pieces you
are responsiule for you would not get very old :-)
if there would be less incompatible config and format changes in the
whole opensource world and way too often changes for the sake of the
change rapid and agile releases would be easier to
handle
but that needs time, work and coordination most are not willing to do
self expierience, our cms is automatically rolled out and db-schemes
applied many times a year to some hundret websites, but in this case
the time spent for 100% predictable update sis worth because it
would eat much more time to roll them out manually and prepare
needed changes by hand - doing so would mean no longer be able
to do agile development by only two people and make it also
impossible to use a leading-edge distribution with rapid cycles
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 1:32 PM, James Peach <jp...@apache.org> wrote:
> On Aug 12, 2013, at 12:22 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> Yes. The goal here is to make the release reliable and predictable so that upgrading is not a scary experience or a lot of work.
>
>>
>> Also, how do we deal with incompatibility changes?
>
> Configurations and data formats should be automatically upgraded. Everything would need to be release noted thoroughly.
Wow, that's a humongous pain in the ass to deal with. I've done this before (Mozilla) and it truly sucks big time to have to deal with this :-/.
Particularly dealing with live upgrading of the cache would be a monumental task, and *incredibly* risky.
I can right now say I'm hugely -1 on this idea. To put it bluntly, I think we'd kill ourselves and the project if we tried. ;)
>
>> Or are you proposing that we from now on, never make anything incompatible? Incompatible he
>> * An API needs to be deprecated (and removed) in order to fix / change something significant. For example, the new cache key proposal comes to mind.
>
> Mark as deprecated, then remove once the support window has passed.
But I'm missing something then. If there's a support window, you are allowing incompatible changes? What does the support window define? "If you are running a version older then <n> months, we'll not support you upgrading to this version" ?
>
>> * New configuration file format(s). [This might be possible to make compatible, by preserving all old config formats as well as the new ones].
>
> Automatic upgrade tools.
These upgrade tools runs as part of starting traffic_server every time you start it ? Meaning, I deploy my old configs, and a new binary, and suddenly the configs in the /etc/ directory are modified for me? That seems like a non-starter already, considering that deployment state is not the same as runtime state.
If you mean providing tools that upgrades my configs, I make new config packages, and push that in conjunction with a binary update, then that's not compatible, right ? Compatible here would imply I can replace the binaries only, and things will just magically work.
>
>> * Remove the incompatibility branch and release cycle. There's only master and the release branch.
>> * Define hard release dates (say, 9/1/2013, 12/1/2013, 3/1/2013 etc.)
>>
>> Does that sum it up ?
>
> Pretty much. I think the only way a rapid release cycle can work is if there is confidence that upgrading never breaks. IMHO, this is a good thing to have independent of the release process, but it's not necessarily easy to achieve. I think that fixed release dates focus the mind and make the process more predictable.
I agree 100% that having backward compatibility can be nice. I think it opens up an enormous can of worm, that will make our project impossible to work with (but, that's just my biased, unscientific opinion, please prove me wrong). This is why the proposal had the additional release cycle for incompatible changes, with a longer release train (say, 1 / year).
I think the fixed dates is a very minor issue in comparison to the compatibility ideas. I personally think it's a step in the wrong direction (the rest of the OpenSource world is moving towards agile methodologies), but I would not oppose fixed release dates if that's the consensus of the community. It certainly does make the release process predictable.
Cheers,
-- leif
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 1:32 PM, James Peach <jp...@apache.org> wrote:
> On Aug 12, 2013, at 12:22 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> Yes. The goal here is to make the release reliable and predictable so that upgrading is not a scary experience or a lot of work.
>
>>
>> Also, how do we deal with incompatibility changes?
>
> Configurations and data formats should be automatically upgraded. Everything would need to be release noted thoroughly.
Wow, that's a humongous pain in the ass to deal with. I've done this before (Mozilla) and it truly sucks big time to have to deal with this :-/.
Particularly dealing with live upgrading of the cache would be a monumental task, and *incredibly* risky.
I can right now say I'm hugely -1 on this idea. To put it bluntly, I think we'd kill ourselves and the project if we tried. ;)
>
>> Or are you proposing that we from now on, never make anything incompatible? Incompatible he
>> * An API needs to be deprecated (and removed) in order to fix / change something significant. For example, the new cache key proposal comes to mind.
>
> Mark as deprecated, then remove once the support window has passed.
But I'm missing something then. If there's a support window, you are allowing incompatible changes? What does the support window define? "If you are running a version older then <n> months, we'll not support you upgrading to this version" ?
>
>> * New configuration file format(s). [This might be possible to make compatible, by preserving all old config formats as well as the new ones].
>
> Automatic upgrade tools.
These upgrade tools runs as part of starting traffic_server every time you start it ? Meaning, I deploy my old configs, and a new binary, and suddenly the configs in the /etc/ directory are modified for me? That seems like a non-starter already, considering that deployment state is not the same as runtime state.
If you mean providing tools that upgrades my configs, I make new config packages, and push that in conjunction with a binary update, then that's not compatible, right ? Compatible here would imply I can replace the binaries only, and things will just magically work.
>
>> * Remove the incompatibility branch and release cycle. There's only master and the release branch.
>> * Define hard release dates (say, 9/1/2013, 12/1/2013, 3/1/2013 etc.)
>>
>> Does that sum it up ?
>
> Pretty much. I think the only way a rapid release cycle can work is if there is confidence that upgrading never breaks. IMHO, this is a good thing to have independent of the release process, but it's not necessarily easy to achieve. I think that fixed release dates focus the mind and make the process more predictable.
I agree 100% that having backward compatibility can be nice. I think it opens up an enormous can of worm, that will make our project impossible to work with (but, that's just my biased, unscientific opinion, please prove me wrong). This is why the proposal had the additional release cycle for incompatible changes, with a longer release train (say, 1 / year).
I think the fixed dates is a very minor issue in comparison to the compatibility ideas. I personally think it's a step in the wrong direction (the rest of the OpenSource world is moving towards agile methodologies), but I would not oppose fixed release dates if that's the consensus of the community. It certainly does make the release process predictable.
Cheers,
-- leif
Re: [PROPOSAL] New release process
Posted by James Peach <jp...@apache.org>.
On Aug 12, 2013, at 12:22 PM, Leif Hedstrom <zw...@apache.org> wrote:
> On Aug 12, 2013, at 1:02 PM, James Peach <jp...@apache.org> wrote:
>
>> On Aug 10, 2013, at 4:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>>>
>>> Please discuss, and lets make the updates to that doc as appropriate. Also, if the consensus is to leave the release process as is, we should make that decision as well in the next 2 weeks.
>>
>> I'm going to ramble a bit here ....
>>
>> The most successful release process I've been a part of was the IRIX release process. We released every 3 months like clockwork. Every release was guaranteed to be forwards and backwards compatible with the previous releases. That strong guarantee is what allows the rapid release cycle to work, because people have confidence that upgrading will not be an unpleasant experience.
>
> 4 releases / year seems very reasonable to me. I'm not sure we can (or should) be on a clockwork cycle, it feels very anti-agile to me personally. For example, what if we need to make a release tomorrow, but it's only been 4 weeks since last release?
If we need to fix a critical bug or security issue, we would have to do an additional release.
> What if there's been no changes worthy of a release, do we still make one?
Yes. The goal here is to make the release reliable and predictable so that upgrading is not a scary experience or a lot of work.
>
> Also, how do we deal with incompatibility changes?
Configurations and data formats should be automatically upgraded. Everything would need to be release noted thoroughly.
> Or are you proposing that we from now on, never make anything incompatible? Incompatible here would be e.g.
>
> * Cache needs to be reinitialized due to changes in layout (this has happened numerous times). It's a real problem for many deployments if the cache has to be reinitialized.
We definitely should not break cache compatibility lightly, if ever.
> * An API needs to be deprecated (and removed) in order to fix / change something significant. For example, the new cache key proposal comes to mind.
Mark as deprecated, then remove once the support window has passed.
> * New configuration file format(s). [This might be possible to make compatible, by preserving all old config formats as well as the new ones].
Automatic upgrade tools.
> I'm sure there are other possible examples, but as far as I know, every major release has broken some backward compatibility so far?
>
>
>>
>> I'm generally in favour of having a single release train that we push regularly. Every three months seems like a reasonable time frame, given the amount of work involved in packaging, deployment and release management. The key to making this work is to prove that we can deliver a strong compatibility guarantee. In order to make a strong compatibility guarantee, we need to make sure that master is always in a releasable state, that we always provide correct configuration upgrade tools, never regress performance, etc. Do we currently have sufficient test and performance coverage to be comfortable that we can do that?
>
> To answer the last question: No, we need much better tools in this area. Power users have to step up to the plate.
>
> If I understand you correctly, you are proposing we are always upgrade compatible, and only have one release train (based on master)? The delta of this to the Wiki proposal would be (correct me if I'm wrong):
>
> * Remove the incompatibility branch and release cycle. There's only master and the release branch.
> * Define hard release dates (say, 9/1/2013, 12/1/2013, 3/1/2013 etc.)
>
> Does that sum it up ?
Pretty much. I think the only way a rapid release cycle can work is if there is confidence that upgrading never breaks. IMHO, this is a good thing to have independent of the release process, but it's not necessarily easy to achieve. I think that fixed release dates focus the mind and make the process more predictable.
J
Re: [PROPOSAL] New release process
Posted by James Peach <jp...@apache.org>.
On Aug 12, 2013, at 12:22 PM, Leif Hedstrom <zw...@apache.org> wrote:
> On Aug 12, 2013, at 1:02 PM, James Peach <jp...@apache.org> wrote:
>
>> On Aug 10, 2013, at 4:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>>>
>>> Please discuss, and lets make the updates to that doc as appropriate. Also, if the consensus is to leave the release process as is, we should make that decision as well in the next 2 weeks.
>>
>> I'm going to ramble a bit here ....
>>
>> The most successful release process I've been a part of was the IRIX release process. We released every 3 months like clockwork. Every release was guaranteed to be forwards and backwards compatible with the previous releases. That strong guarantee is what allows the rapid release cycle to work, because people have confidence that upgrading will not be an unpleasant experience.
>
> 4 releases / year seems very reasonable to me. I'm not sure we can (or should) be on a clockwork cycle, it feels very anti-agile to me personally. For example, what if we need to make a release tomorrow, but it's only been 4 weeks since last release?
If we need to fix a critical bug or security issue, we would have to do an additional release.
> What if there's been no changes worthy of a release, do we still make one?
Yes. The goal here is to make the release reliable and predictable so that upgrading is not a scary experience or a lot of work.
>
> Also, how do we deal with incompatibility changes?
Configurations and data formats should be automatically upgraded. Everything would need to be release noted thoroughly.
> Or are you proposing that we from now on, never make anything incompatible? Incompatible here would be e.g.
>
> * Cache needs to be reinitialized due to changes in layout (this has happened numerous times). It's a real problem for many deployments if the cache has to be reinitialized.
We definitely should not break cache compatibility lightly, if ever.
> * An API needs to be deprecated (and removed) in order to fix / change something significant. For example, the new cache key proposal comes to mind.
Mark as deprecated, then remove once the support window has passed.
> * New configuration file format(s). [This might be possible to make compatible, by preserving all old config formats as well as the new ones].
Automatic upgrade tools.
> I'm sure there are other possible examples, but as far as I know, every major release has broken some backward compatibility so far?
>
>
>>
>> I'm generally in favour of having a single release train that we push regularly. Every three months seems like a reasonable time frame, given the amount of work involved in packaging, deployment and release management. The key to making this work is to prove that we can deliver a strong compatibility guarantee. In order to make a strong compatibility guarantee, we need to make sure that master is always in a releasable state, that we always provide correct configuration upgrade tools, never regress performance, etc. Do we currently have sufficient test and performance coverage to be comfortable that we can do that?
>
> To answer the last question: No, we need much better tools in this area. Power users have to step up to the plate.
>
> If I understand you correctly, you are proposing we are always upgrade compatible, and only have one release train (based on master)? The delta of this to the Wiki proposal would be (correct me if I'm wrong):
>
> * Remove the incompatibility branch and release cycle. There's only master and the release branch.
> * Define hard release dates (say, 9/1/2013, 12/1/2013, 3/1/2013 etc.)
>
> Does that sum it up ?
Pretty much. I think the only way a rapid release cycle can work is if there is confidence that upgrading never breaks. IMHO, this is a good thing to have independent of the release process, but it's not necessarily easy to achieve. I think that fixed release dates focus the mind and make the process more predictable.
J
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 1:02 PM, James Peach <jp...@apache.org> wrote:
> On Aug 10, 2013, at 4:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>>
>> Please discuss, and lets make the updates to that doc as appropriate. Also, if the consensus is to leave the release process as is, we should make that decision as well in the next 2 weeks.
>
> I'm going to ramble a bit here ....
>
> The most successful release process I've been a part of was the IRIX release process. We released every 3 months like clockwork. Every release was guaranteed to be forwards and backwards compatible with the previous releases. That strong guarantee is what allows the rapid release cycle to work, because people have confidence that upgrading will not be an unpleasant experience.
4 releases / year seems very reasonable to me. I'm not sure we can (or should) be on a clockwork cycle, it feels very anti-agile to me personally. For example, what if we need to make a release tomorrow, but it's only been 4 weeks since last release? What if there's been no changes worthy of a release, do we still make one?
Also, how do we deal with incompatibility changes? Or are you proposing that we from now on, never make anything incompatible? Incompatible here would be e.g.
* Cache needs to be reinitialized due to changes in layout (this has happened numerous times). It's a real problem for many deployments if the cache has to be reinitialized.
* An API needs to be deprecated (and removed) in order to fix / change something significant. For example, the new cache key proposal comes to mind.
* New configuration file format(s). [This might be possible to make compatible, by preserving all old config formats as well as the new ones].
I'm sure there are other possible examples, but as far as I know, every major release has broken some backward compatibility so far?
>
> I'm generally in favour of having a single release train that we push regularly. Every three months seems like a reasonable time frame, given the amount of work involved in packaging, deployment and release management. The key to making this work is to prove that we can deliver a strong compatibility guarantee. In order to make a strong compatibility guarantee, we need to make sure that master is always in a releasable state, that we always provide correct configuration upgrade tools, never regress performance, etc. Do we currently have sufficient test and performance coverage to be comfortable that we can do that?
To answer the last question: No, we need much better tools in this area. Power users have to step up to the plate.
If I understand you correctly, you are proposing we are always upgrade compatible, and only have one release train (based on master)? The delta of this to the Wiki proposal would be (correct me if I'm wrong):
* Remove the incompatibility branch and release cycle. There's only master and the release branch.
* Define hard release dates (say, 9/1/2013, 12/1/2013, 3/1/2013 etc.)
Does that sum it up ?
Cheers,
-- Leif
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 1:02 PM, James Peach <jp...@apache.org> wrote:
> On Aug 10, 2013, at 4:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>>
>> Please discuss, and lets make the updates to that doc as appropriate. Also, if the consensus is to leave the release process as is, we should make that decision as well in the next 2 weeks.
>
> I'm going to ramble a bit here ....
>
> The most successful release process I've been a part of was the IRIX release process. We released every 3 months like clockwork. Every release was guaranteed to be forwards and backwards compatible with the previous releases. That strong guarantee is what allows the rapid release cycle to work, because people have confidence that upgrading will not be an unpleasant experience.
4 releases / year seems very reasonable to me. I'm not sure we can (or should) be on a clockwork cycle, it feels very anti-agile to me personally. For example, what if we need to make a release tomorrow, but it's only been 4 weeks since last release? What if there's been no changes worthy of a release, do we still make one?
Also, how do we deal with incompatibility changes? Or are you proposing that we from now on, never make anything incompatible? Incompatible here would be e.g.
* Cache needs to be reinitialized due to changes in layout (this has happened numerous times). It's a real problem for many deployments if the cache has to be reinitialized.
* An API needs to be deprecated (and removed) in order to fix / change something significant. For example, the new cache key proposal comes to mind.
* New configuration file format(s). [This might be possible to make compatible, by preserving all old config formats as well as the new ones].
I'm sure there are other possible examples, but as far as I know, every major release has broken some backward compatibility so far?
>
> I'm generally in favour of having a single release train that we push regularly. Every three months seems like a reasonable time frame, given the amount of work involved in packaging, deployment and release management. The key to making this work is to prove that we can deliver a strong compatibility guarantee. In order to make a strong compatibility guarantee, we need to make sure that master is always in a releasable state, that we always provide correct configuration upgrade tools, never regress performance, etc. Do we currently have sufficient test and performance coverage to be comfortable that we can do that?
To answer the last question: No, we need much better tools in this area. Power users have to step up to the plate.
If I understand you correctly, you are proposing we are always upgrade compatible, and only have one release train (based on master)? The delta of this to the Wiki proposal would be (correct me if I'm wrong):
* Remove the incompatibility branch and release cycle. There's only master and the release branch.
* Define hard release dates (say, 9/1/2013, 12/1/2013, 3/1/2013 etc.)
Does that sum it up ?
Cheers,
-- Leif
Re: [PROPOSAL] New release process
Posted by James Peach <jp...@apache.org>.
On Aug 10, 2013, at 4:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
> Hi all,
>
> I started a wiki with some ideas on how to streamline and simplify the release process:
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
>
> I'd like to start the discussion on this, and come to a consensus before next stable release. One key decision here is what the next stable release should be versioned (I'm suggesting we make it v4.0, with no micro version). The alternative is to keep it as we had planned, which would be v3.4.0.
>
> Please discuss, and lets make the updates to that doc as appropriate. Also, if the consensus is to leave the release process as is, we should make that decision as well in the next 2 weeks.
I'm going to ramble a bit here ....
The most successful release process I've been a part of was the IRIX release process. We released every 3 months like clockwork. Every release was guaranteed to be forwards and backwards compatible with the previous releases. That strong guarantee is what allows the rapid release cycle to work, because people have confidence that upgrading will not be an unpleasant experience.
I'm generally in favour of having a single release train that we push regularly. Every three months seems like a reasonable time frame, given the amount of work involved in packaging, deployment and release management. The key to making this work is to prove that we can deliver a strong compatibility guarantee. In order to make a strong compatibility guarantee, we need to make sure that master is always in a releasable state, that we always provide correct configuration upgrade tools, never regress performance, etc. Do we currently have sufficient test and performance coverage to be comfortable that we can do that?
We would also need to define a support period, and be prepared to support all the releases within that period. This might interact poorly with Linux distributions, many of which will have longer release cycles. OTOH, if we can do compatibility correctly, maybe they would feel comfortable shipping the latest release in point updates ...
J
Re: [LAST CALL] [PROPOSAL] New release process
Posted by Igor Galić <i....@brainsware.org>.
+1
----- Original Message -----
>
> On Aug 15, 2013, at 9:30 AM, Igor Galić <i....@brainsware.org> wrote:
>
> > I think enough time on this has passed that we can call everyone to review
> > the current draft in the wiki:
>
> Alright, I'm going to make a last call on this. Are there any objects to the
> proposal as it is right now at
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
> ? If not, we'll move along with this. A quick summary of what this means:
>
>
> 1) SemVer is in place as of right now (http://semver.org).
>
> 2) There are no more development releases (only "stable" releases).
>
> 3) The next (as in, end of August) stable release will be v4.0.0.
>
> 4) Master should be kept stable and compatible within the major versioning.
>
>
>
> Unless there's some late objections to this, we'll start the work on changing
> Jira and git to reflect this on Wednesday this week (in prep for v4.0.0
> release).
>
> Cheers,
>
> -- Leif
>
>
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [LAST CALL] [PROPOSAL] New release process
Posted by Bryan Call <bc...@yahoo-inc.com>.
+1
-Bryan
On Aug 19, 2013, at 2:18 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> On Aug 15, 2013, at 9:30 AM, Igor Galić <i....@brainsware.org> wrote:
>
>> I think enough time on this has passed that we can call everyone to review the current draft in the wiki:
>
> Alright, I'm going to make a last call on this. Are there any objects to the proposal as it is right now at
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
> ? If not, we'll move along with this. A quick summary of what this means:
>
>
> 1) SemVer is in place as of right now (http://semver.org).
>
> 2) There are no more development releases (only "stable" releases).
>
> 3) The next (as in, end of August) stable release will be v4.0.0.
>
> 4) Master should be kept stable and compatible within the major versioning.
>
>
>
> Unless there's some late objections to this, we'll start the work on changing Jira and git to reflect this on Wednesday this week (in prep for v4.0.0 release).
>
> Cheers,
>
> -- Leif
>
Re: [LAST CALL] [PROPOSAL] New release process
Posted by Yongming Zhao <mi...@gmail.com>.
+1
need more focus on the testing(QA) tools, it is hard but must
在 2013-8-20，上午5:18，Leif Hedstrom <zw...@apache.org> 写道：
>
> On Aug 15, 2013, at 9:30 AM, Igor Galić <i....@brainsware.org> wrote:
>
>> I think enough time on this has passed that we can call everyone to review the current draft in the wiki:
>
> Alright, I'm going to make a last call on this. Are there any objects to the proposal as it is right now at
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
> ? If not, we'll move along with this. A quick summary of what this means:
>
>
> 1) SemVer is in place as of right now (http://semver.org).
>
> 2) There are no more development releases (only "stable" releases).
>
> 3) The next (as in, end of August) stable release will be v4.0.0.
>
> 4) Master should be kept stable and compatible within the major versioning.
>
>
>
> Unless there's some late objections to this, we'll start the work on changing Jira and git to reflect this on Wednesday this week (in prep for v4.0.0 release).
>
> Cheers,
>
> -- Leif
>
Re: [LAST CALL] [PROPOSAL] New release process
Posted by James Peach <jp...@apache.org>.
On Aug 19, 2013, at 2:18 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> On Aug 15, 2013, at 9:30 AM, Igor Galić <i....@brainsware.org> wrote:
>
>> I think enough time on this has passed that we can call everyone to review the current draft in the wiki:
>
> Alright, I'm going to make a last call on this. Are there any objects to the proposal as it is right now at
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
> ? If not, we'll move along with this. A quick summary of what this means:
>
>
> 1) SemVer is in place as of right now (http://semver.org).
>
> 2) There are no more development releases (only "stable" releases).
>
> 3) The next (as in, end of August) stable release will be v4.0.0.
>
> 4) Master should be kept stable and compatible within the major versioning.
+1
I added a wiki link to semver.org
[LAST CALL] [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 15, 2013, at 9:30 AM, Igor Galić <i....@brainsware.org> wrote:
> I think enough time on this has passed that we can call everyone to review the current draft in the wiki:
Alright, I'm going to make a last call on this. Are there any objects to the proposal as it is right now at
https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
? If not, we'll move along with this. A quick summary of what this means:
1) SemVer is in place as of right now (http://semver.org).
2) There are no more development releases (only "stable" releases).
3) The next (as in, end of August) stable release will be v4.0.0.
4) Master should be kept stable and compatible within the major versioning.
Unless there's some late objections to this, we'll start the work on changing Jira and git to reflect this on Wednesday this week (in prep for v4.0.0 release).
Cheers,
-- Leif
Re: [PROPOSAL] New release process
Posted by Igor Galić <i....@brainsware.org>.
I think enough time on this has passed that we can call everyone to review the current draft in the wiki:
https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
and perhaps also (re?)read about Semantic Versioning, which our proposal is very tightly coupled with:
http://semver.org/
if this current proposal is clear and uncontroversial enough, we could move on to deciding about specifics, such as which version to start with, how to handle the transition in Jira, and which of the currently released branches should be considered LTS, etc..
So long,
i
----- Original Message -----
> On Mon, Aug 12, 2013 at 5:40 PM, Leif Hedstrom < zwoop@apache.org > wrote:
> > On Aug 12, 2013, at 5:10 PM, Igor Galić < i.galic@brainsware.org > wrote:
>
> > https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
> > >
>
> > >
>
> > > This was exactly my problem at first. Leif was going with his proposal in
> > > one big zwoop from odd/even (-dev/stable) major.minor.patch releases to
> > > *just* major.minor releases (he's fixed that bit in the wiki by now)
>
> > >
>
> > Yes, I restored the major.minor.micro version concept. Sorry for
> > obfuscating
> > the issue unnecessarily. The updated proposals are still on
>
> > From what I can gather, the issue of contention is how to deal with
> > incompatible changes. We're all in violent agreement that our long standing
> > rule of not breaking compatibility within stable releases through the year
> > is a given (e.g. 3.2.0 to v3.2.1 should always be safe).
>
> > Cheers,
>
> > -- Leif
>
> I talked with Leif about this in person and I may be coming around to the
> idea.
> The versioning would follow http://semver.org/ . The PATCH version would
> essentially be used to do the version burn on a bad release vote and also
> for the LTS versions before the next MAJOR release. The LTS release (which
> is a new wrinkle Leif mentioned and I added to the wiki) would be something
> the more conservative amongst us. Those who chose to run LTS could test the
> other releases as if they were new feature dev releases leading up to the
> next LTS release. The more adventurous would run the MINOR updates as they
> came out quarterly. It's kinda like the best of both worlds in a way.
> We just need to make sure to keep Alan committing on the
> incompatible-next-major-release branch. :)
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [PROPOSAL] New release process
Posted by Igor Galić <i....@brainsware.org>.
I think enough time on this has passed that we can call everyone to review the current draft in the wiki:
https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
and perhaps also (re?)read about Semantic Versioning, which our proposal is very tightly coupled with:
http://semver.org/
if this current proposal is clear and uncontroversial enough, we could move on to deciding about specifics, such as which version to start with, how to handle the transition in Jira, and which of the currently released branches should be considered LTS, etc..
So long,
i
----- Original Message -----
> On Mon, Aug 12, 2013 at 5:40 PM, Leif Hedstrom < zwoop@apache.org > wrote:
> > On Aug 12, 2013, at 5:10 PM, Igor Galić < i.galic@brainsware.org > wrote:
>
> > https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
> > >
>
> > >
>
> > > This was exactly my problem at first. Leif was going with his proposal in
> > > one big zwoop from odd/even (-dev/stable) major.minor.patch releases to
> > > *just* major.minor releases (he's fixed that bit in the wiki by now)
>
> > >
>
> > Yes, I restored the major.minor.micro version concept. Sorry for
> > obfuscating
> > the issue unnecessarily. The updated proposals are still on
>
> > From what I can gather, the issue of contention is how to deal with
> > incompatible changes. We're all in violent agreement that our long standing
> > rule of not breaking compatibility within stable releases through the year
> > is a given (e.g. 3.2.0 to v3.2.1 should always be safe).
>
> > Cheers,
>
> > -- Leif
>
> I talked with Leif about this in person and I may be coming around to the
> idea.
> The versioning would follow http://semver.org/ . The PATCH version would
> essentially be used to do the version burn on a bad release vote and also
> for the LTS versions before the next MAJOR release. The LTS release (which
> is a new wrinkle Leif mentioned and I added to the wiki) would be something
> the more conservative amongst us. Those who chose to run LTS could test the
> other releases as if they were new feature dev releases leading up to the
> next LTS release. The more adventurous would run the MINOR updates as they
> came out quarterly. It's kinda like the best of both worlds in a way.
> We just need to make sure to keep Alan committing on the
> incompatible-next-major-release branch. :)
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [PROPOSAL] New release process
Posted by Phil Sorber <so...@apache.org>.
On Mon, Aug 12, 2013 at 5:40 PM, Leif Hedstrom <zw...@apache.org> wrote:
> On Aug 12, 2013, at 5:10 PM, Igor Galić <i....@brainsware.org> wrote:
>
> >
> >
> > This was exactly my problem at first. Leif was going with his proposal
> in one big zwoop from odd/even (-dev/stable) major.minor.patch releases to
> *just* major.minor releases (he's fixed that bit in the wiki by now)
> >
>
> Yes, I restored the major.minor.micro version concept. Sorry for
> obfuscating the issue unnecessarily. The updated proposals are still on
>
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
>
> From what I can gather, the issue of contention is how to deal with
> incompatible changes. We're all in violent agreement that our long standing
> rule of not breaking compatibility within stable releases through the year
> is a given (e.g. 3.2.0 to v3.2.1 should always be safe).
>
> Cheers,
>
> -- Leif
>
>
I talked with Leif about this in person and I may be coming around to the
idea.
The versioning would follow http://semver.org/. The PATCH version would
essentially be used to do the version burn on a bad release vote and also
for the LTS versions before the next MAJOR release. The LTS release (which
is a new wrinkle Leif mentioned and I added to the wiki) would be something
the more conservative amongst us. Those who chose to run LTS could test the
other releases as if they were new feature dev releases leading up to the
next LTS release. The more adventurous would run the MINOR updates as they
came out quarterly. It's kinda like the best of both worlds in a way.
We just need to make sure to keep Alan committing on the
incompatible-next-major-release branch. :)
Re: [PROPOSAL] New release process
Posted by Phil Sorber <so...@apache.org>.
On Mon, Aug 12, 2013 at 5:40 PM, Leif Hedstrom <zw...@apache.org> wrote:
> On Aug 12, 2013, at 5:10 PM, Igor Galić <i....@brainsware.org> wrote:
>
> >
> >
> > This was exactly my problem at first. Leif was going with his proposal
> in one big zwoop from odd/even (-dev/stable) major.minor.patch releases to
> *just* major.minor releases (he's fixed that bit in the wiki by now)
> >
>
> Yes, I restored the major.minor.micro version concept. Sorry for
> obfuscating the issue unnecessarily. The updated proposals are still on
>
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
>
> From what I can gather, the issue of contention is how to deal with
> incompatible changes. We're all in violent agreement that our long standing
> rule of not breaking compatibility within stable releases through the year
> is a given (e.g. 3.2.0 to v3.2.1 should always be safe).
>
> Cheers,
>
> -- Leif
>
>
I talked with Leif about this in person and I may be coming around to the
idea.
The versioning would follow http://semver.org/. The PATCH version would
essentially be used to do the version burn on a bad release vote and also
for the LTS versions before the next MAJOR release. The LTS release (which
is a new wrinkle Leif mentioned and I added to the wiki) would be something
the more conservative amongst us. Those who chose to run LTS could test the
other releases as if they were new feature dev releases leading up to the
next LTS release. The more adventurous would run the MINOR updates as they
came out quarterly. It's kinda like the best of both worlds in a way.
We just need to make sure to keep Alan committing on the
incompatible-next-major-release branch. :)
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 5:10 PM, Igor Galić <i....@brainsware.org> wrote:
>
>
> This was exactly my problem at first. Leif was going with his proposal in one big zwoop from odd/even (-dev/stable) major.minor.patch releases to *just* major.minor releases (he's fixed that bit in the wiki by now)
>
Yes, I restored the major.minor.micro version concept. Sorry for obfuscating the issue unnecessarily. The updated proposals are still on
https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
From what I can gather, the issue of contention is how to deal with incompatible changes. We're all in violent agreement that our long standing rule of not breaking compatibility within stable releases through the year is a given (e.g. 3.2.0 to v3.2.1 should always be safe).
Cheers,
-- Leif
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 5:10 PM, Igor Galić <i....@brainsware.org> wrote:
>
>
> This was exactly my problem at first. Leif was going with his proposal in one big zwoop from odd/even (-dev/stable) major.minor.patch releases to *just* major.minor releases (he's fixed that bit in the wiki by now)
>
Yes, I restored the major.minor.micro version concept. Sorry for obfuscating the issue unnecessarily. The updated proposals are still on
https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
From what I can gather, the issue of contention is how to deal with incompatible changes. We're all in violent agreement that our long standing rule of not breaking compatibility within stable releases through the year is a given (e.g. 3.2.0 to v3.2.1 should always be safe).
Cheers,
-- Leif
Re: [PROPOSAL] New release process
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> On Mon, Aug 12, 2013 at 4:05 PM, Leif Hedstrom < leif@ogre.com > wrote:
> > On Aug 12, 2013, at 3:40 PM, Igor Galić < i.galic@brainsware.org > wrote
>
> > >
>
> > >
>
> > > ----- Original Message -----
>
> > >> On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom < zwoop@apache.org >
> > >> wrote:
>
> > >>
>
> > >>> e currently merge master into a dev branch to make a dev release. I
> > >>> feel
>
> > >> like master and dev should be synonymous.
>
> > >
>
> > > I never quite understood why Leif felt the need to create a (temporary)
>
> > > -dev release branch. (but then I'm only starting to comprehend git)
>
> > That was a mistake. However, the 3.3.x branch had a real purpose for my
> > RM'ing, just as the "4.x" branch in the WIki propopsal:
>
> > Imagine that you are making a release out of Master. You "git pull" it,
> > look
> > at the changes (hopefully), make some tests, build it, etc., maybe fix a
> > bug
> > or two. In the mean time, Phil commits 100 changes to master. What do you
> > tag now for your release?
>
> > Granted you can tag as soon as you start your process, and as you make
> > changes, fixes or whatever, you retag accordingly. The 3.3.x branch was
> > made
> > to make this process easier.
>
> > To be honest, I don't care about this at all. The 3.3.x branch was a tool
> > to
> > make my life easier, if other RMs have better tools or other methodologies,
> > by all means, use those. Neither of the proposals or changes depend on
> > this,
> > and I hope we can avoid getting hung up on technicalities on how git works
> > ;).
>
> > >
>
> > >> Ifor software of this nature. 1 a year is maybe too little from a
>
> > >> features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3
> > >> times
>
> > >> a year seems reasonable to me. Probably closer to 2.
>
> > >
>
> > > really? even two seems too much to me, but maybe growing up with httpd
>
> > > I'm thinking too conservatively.
>
> > Fwiw, we had these discussions early on, and the general consensus was the
> > releasing early and often was the way to go. We can change that, it's what
> > a
> > healthy community is all about. Fwiw, HTTPD releases fairly often: 25
> > releases of v2.2 and already 6 releases for v2.4. The latter is roughly 4
> > releases per year (2.4.0 was released early 2012, right ?). What I think
> > HTTPD did different was very long times between major relies (v2.2 to
> > v2.4).
>
> I think I just had an epiphany about your proposal. I think there are two
> pieces here that combined have confused me, and maybe others. You'd like to
> make more stable "micro" releases, up to 4 times a year. Then you'd also
> like to roll the micro release number into the minor number. So instead of
> 3.4.1 we just have 3.5. Or am I even further in the weeds now?
This was exactly my problem at first. Leif was going with his proposal in one big zwoop from odd/even (-dev/stable) major.minor.patch releases to *just* major.minor releases (he's fixed that bit in the wiki by now)
But that's where he lost at least a couple of us (me and Phil, and probably a good number of those "following" the thread but not commenting yet). The reason was simply because it conflated two concepts. Those two concepts however have no meaning once we put this new Release Process into place.
You know, after we decided what it's supposed to look like. Which is what we're trying to do right now ;)
> > Cheers,
>
> > -- leif
>
-- i
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [PROPOSAL] New release process
Posted by Phil Sorber <so...@apache.org>.
On Mon, Aug 12, 2013 at 4:05 PM, Leif Hedstrom <le...@ogre.com> wrote:
>
> On Aug 12, 2013, at 3:40 PM, Igor Galić <i....@brainsware.org> wrote
> >
> >
> > ----- Original Message -----
> >> On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zw...@apache.org>
> wrote:
> >>
> >>> e currently merge master into a dev branch to make a dev release. I
> feel
> >> like master and dev should be synonymous.
> >
> > I never quite understood why Leif felt the need to create a (temporary)
> > -dev release branch. (but then I'm only starting to comprehend git)
>
> That was a mistake. However, the 3.3.x branch had a real purpose for my
> RM'ing, just as the "4.x" branch in the WIki propopsal:
>
> Imagine that you are making a release out of Master. You "git pull" it,
> look at the changes (hopefully), make some tests, build it, etc., maybe fix
> a bug or two. In the mean time, Phil commits 100 changes to master. What do
> you tag now for your release?
>
> Granted you can tag as soon as you start your process, and as you make
> changes, fixes or whatever, you retag accordingly. The 3.3.x branch was
> made to make this process easier.
>
> To be honest, I don't care about this at all. The 3.3.x branch was a tool
> to make my life easier, if other RMs have better tools or other
> methodologies, by all means, use those. Neither of the proposals or changes
> depend on this, and I hope we can avoid getting hung up on technicalities
> on how git works ;).
>
> >
> >> Ifor software of this nature. 1 a year is maybe too little from a
> >> features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3
> times
> >> a year seems reasonable to me. Probably closer to 2.
> >
> > really? even two seems too much to me, but maybe growing up with httpd
> > I'm thinking too conservatively.
>
> Fwiw, we had these discussions early on, and the general consensus was the
> releasing early and often was the way to go. We can change that, it's what
> a healthy community is all about. Fwiw, HTTPD releases fairly often: 25
> releases of v2.2 and already 6 releases for v2.4. The latter is roughly 4
> releases per year (2.4.0 was released early 2012, right ?). What I think
> HTTPD did different was very long times between major relies (v2.2 to v2.4).
>
>
I think I just had an epiphany about your proposal. I think there are two
pieces here that combined have confused me, and maybe others. You'd like to
make more stable "micro" releases, up to 4 times a year. Then you'd also
like to roll the micro release number into the minor number. So instead of
3.4.1 we just have 3.5. Or am I even further in the weeds now?
> Cheers,
>
> -- leif
>
>
Re: [PROPOSAL] New release process
Posted by Phil Sorber <so...@apache.org>.
On Mon, Aug 12, 2013 at 4:05 PM, Leif Hedstrom <le...@ogre.com> wrote:
>
> On Aug 12, 2013, at 3:40 PM, Igor Galić <i....@brainsware.org> wrote
> >
> >
> > ----- Original Message -----
> >> On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zw...@apache.org>
> wrote:
> >>
> >>> e currently merge master into a dev branch to make a dev release. I
> feel
> >> like master and dev should be synonymous.
> >
> > I never quite understood why Leif felt the need to create a (temporary)
> > -dev release branch. (but then I'm only starting to comprehend git)
>
> That was a mistake. However, the 3.3.x branch had a real purpose for my
> RM'ing, just as the "4.x" branch in the WIki propopsal:
>
> Imagine that you are making a release out of Master. You "git pull" it,
> look at the changes (hopefully), make some tests, build it, etc., maybe fix
> a bug or two. In the mean time, Phil commits 100 changes to master. What do
> you tag now for your release?
>
> Granted you can tag as soon as you start your process, and as you make
> changes, fixes or whatever, you retag accordingly. The 3.3.x branch was
> made to make this process easier.
>
> To be honest, I don't care about this at all. The 3.3.x branch was a tool
> to make my life easier, if other RMs have better tools or other
> methodologies, by all means, use those. Neither of the proposals or changes
> depend on this, and I hope we can avoid getting hung up on technicalities
> on how git works ;).
>
> >
> >> Ifor software of this nature. 1 a year is maybe too little from a
> >> features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3
> times
> >> a year seems reasonable to me. Probably closer to 2.
> >
> > really? even two seems too much to me, but maybe growing up with httpd
> > I'm thinking too conservatively.
>
> Fwiw, we had these discussions early on, and the general consensus was the
> releasing early and often was the way to go. We can change that, it's what
> a healthy community is all about. Fwiw, HTTPD releases fairly often: 25
> releases of v2.2 and already 6 releases for v2.4. The latter is roughly 4
> releases per year (2.4.0 was released early 2012, right ?). What I think
> HTTPD did different was very long times between major relies (v2.2 to v2.4).
>
>
I think I just had an epiphany about your proposal. I think there are two
pieces here that combined have confused me, and maybe others. You'd like to
make more stable "micro" releases, up to 4 times a year. Then you'd also
like to roll the micro release number into the minor number. So instead of
3.4.1 we just have 3.5. Or am I even further in the weeds now?
> Cheers,
>
> -- leif
>
>
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <le...@ogre.com>.
On Aug 12, 2013, at 3:40 PM, Igor Galić <i....@brainsware.org> wrote
>
>
> ----- Original Message -----
>> On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>>> e currently merge master into a dev branch to make a dev release. I feel
>> like master and dev should be synonymous.
>
> I never quite understood why Leif felt the need to create a (temporary)
> -dev release branch. (but then I'm only starting to comprehend git)
That was a mistake. However, the 3.3.x branch had a real purpose for my RM'ing, just as the "4.x" branch in the WIki propopsal:
Imagine that you are making a release out of Master. You "git pull" it, look at the changes (hopefully), make some tests, build it, etc., maybe fix a bug or two. In the mean time, Phil commits 100 changes to master. What do you tag now for your release?
Granted you can tag as soon as you start your process, and as you make changes, fixes or whatever, you retag accordingly. The 3.3.x branch was made to make this process easier.
To be honest, I don't care about this at all. The 3.3.x branch was a tool to make my life easier, if other RMs have better tools or other methodologies, by all means, use those. Neither of the proposals or changes depend on this, and I hope we can avoid getting hung up on technicalities on how git works ;).
>
>> Ifor software of this nature. 1 a year is maybe too little from a
>> features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3 times
>> a year seems reasonable to me. Probably closer to 2.
>
> really? even two seems too much to me, but maybe growing up with httpd
> I'm thinking too conservatively.
Fwiw, we had these discussions early on, and the general consensus was the releasing early and often was the way to go. We can change that, it's what a healthy community is all about. Fwiw, HTTPD releases fairly often: 25 releases of v2.2 and already 6 releases for v2.4. The latter is roughly 4 releases per year (2.4.0 was released early 2012, right ?). What I think HTTPD did different was very long times between major relies (v2.2 to v2.4).
Cheers,
-- leif
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 3:40 PM, Igor Galić <i....@brainsware.org> wrote
>
>
> ----- Original Message -----
>> On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>>> e currently merge master into a dev branch to make a dev release. I feel
>> like master and dev should be synonymous.
>
> I never quite understood why Leif felt the need to create a (temporary)
> -dev release branch. (but then I'm only starting to comprehend git)
That was a mistake. However, the 3.3.x branch had a real purpose for my RM'ing, just as the "4.x" branch in the WIki propopsal:
Imagine that you are making a release out of Master. You "git pull" it, look at the changes (hopefully), make some tests, build it, etc., maybe fix a bug or two. In the mean time, Phil commits 100 changes to master. What do you tag now for your release?
Granted you can tag as soon as you start your process, and as you make changes, fixes or whatever, you retag accordingly. The 3.3.x branch was made to make this process easier.
To be honest, I don't care about this at all. The 3.3.x branch was a tool to make my life easier, if other RMs have better tools or other methodologies, by all means, use those. Neither of the proposals or changes depend on this, and I hope we can avoid getting hung up on technicalities on how git works ;).
>
>> Ifor software of this nature. 1 a year is maybe too little from a
>> features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3 times
>> a year seems reasonable to me. Probably closer to 2.
>
> really? even two seems too much to me, but maybe growing up with httpd
> I'm thinking too conservatively.
Fwiw, we had these discussions early on, and the general consensus was the releasing early and often was the way to go. We can change that, it's what a healthy community is all about. Fwiw, HTTPD releases fairly often: 25 releases of v2.2 and already 6 releases for v2.4. The latter is roughly 4 releases per year (2.4.0 was released early 2012, right ?). What I think HTTPD did different was very long times between major relies (v2.2 to v2.4).
Cheers,
-- leif
Re: [PROPOSAL] New release process
Posted by Phil Sorber <so...@apache.org>.
On Mon, Aug 12, 2013 at 3:40 PM, Igor Galić <i....@brainsware.org> wrote:
>
>
> ----- Original Message -----
> > On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
> >
> > > Hi all,
> > >
> > > I started a wiki with some ideas on how to streamline and simplify the
> > > release process:
> > >
> > >
> > > https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
> > >
> > >
> > > I'd like to start the discussion on this, and come to a consensus
> before
> > > next stable release. One key decision here is what the next stable
> release
> > > should be versioned (I'm suggesting we make it v4.0, with no micro
> > > version). The alternative is to keep it as we had planned, which would
> be
> > > v3.4.0.
> > >
> > > Please discuss, and lets make the updates to that doc as appropriate.
> > > Also, if the consensus is to leave the release process as is, we should
> > > make that decision as well in the next 2 weeks.
> > >
> > > Cheers,
> > >
> > > -- leif
> > >
> > >
> > >
> > I think this is going in the wrong direction, personally. I don't like
> how
> > we currently merge master into a dev branch to make a dev release. I feel
> > like master and dev should be synonymous.
>
> I never quite understood why Leif felt the need to create a (temporary)
> -dev release branch. (but then I'm only starting to comprehend git)
>
> > I don't think we've gotten enough testing on dev releases in the past,
> but
> > I think that is changing now. I think we are close to achieving critical
> > mass as far as participation goes. And I think that would only improve if
> > dev and master were closer.
> >
> > As far as backporting goes, I think we should keep that to a minimum. We
> > shouldn't be putting in new features. Only major bugs and security fixes.
> > If people are longing for new features that are in the current stable
> > release then we should be doing stable releases more often.
>
> That's the way I've been handling it so far, and whoever follows me
> as RM I hope does the same.
>
> > And as far as stable releases go I think we should do a little more
> > planning. Much like we were able to do at the summit in Denver. Lets plan
> > out what new features we think we can reasonably get into a release with
> a
> > targetted time frame, but not let time dictate our releases. We should
> have
> > a roadmap available for our users. Lets just agree to have annual or
> > bi-annual summits to hash this stuff out.
> >
> > Within those parameters I think it would be easiest to not have dev
> > branches at all, and just put dev release tags on master. Then when we
> feel
> > we have met our feature requirements for a release (and feel free to add
> or
> > subtract as things move along during the cycle) then we branch a stable
> > branch and then do stabilzation on that branch until we feel it's ready
> for
> > the first stable release. New development can happen concurrently on
> > master, but ideally we'd focus on stabilizing the release branch for the
> > upcoming stable release.
> >
> > I think 4 releases a year is too much from a testing/deployment
> perspective
> > for software of this nature. 1 a year is maybe too little from a
> > features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3
> times
> > a year seems reasonable to me. Probably closer to 2.
>
> really? even two seems too much to me, but maybe growing up with httpd
> I'm thinking too conservatively.
>
>
I think we'd need to find the sweet spot. I think waiting too long people
start complaining about not having feature X available in a stable release
yet. Maybe we need to start with 2-3 a year then in a couple years settle
out at 1 a year. I think right now there's so much to be done that we could
sustain 2/year without a problem.
In fact if there was some hybrid proposal that started off faster and
looser and came into something stricter I might be able to get behind that.
I just don't feel like I can +1 something that I don't see working long
term.
> > When we want to break some major compatibility like on disk format of the
> > cache (assuming we haven't gotten to some plugable model that negates
> this)
> > we would bump the major version, ie 3.x to 4.x. Definitely not more than
> > once a year, but probably more like once every 2+ years. I think we just
> > need to roadmap out those changes appropriately.
> >
> > Sorry, this is a bit of a stream of consciousness but I was trying to
> > adjust my response as this thread grew.
> >
>
> i
>
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.galic@brainsware.org
> URL: http://brainsware.org/
> GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
>
>
Re: [PROPOSAL] New release process
Posted by Phil Sorber <so...@apache.org>.
On Mon, Aug 12, 2013 at 3:40 PM, Igor Galić <i....@brainsware.org> wrote:
>
>
> ----- Original Message -----
> > On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
> >
> > > Hi all,
> > >
> > > I started a wiki with some ideas on how to streamline and simplify the
> > > release process:
> > >
> > >
> > > https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
> > >
> > >
> > > I'd like to start the discussion on this, and come to a consensus
> before
> > > next stable release. One key decision here is what the next stable
> release
> > > should be versioned (I'm suggesting we make it v4.0, with no micro
> > > version). The alternative is to keep it as we had planned, which would
> be
> > > v3.4.0.
> > >
> > > Please discuss, and lets make the updates to that doc as appropriate.
> > > Also, if the consensus is to leave the release process as is, we should
> > > make that decision as well in the next 2 weeks.
> > >
> > > Cheers,
> > >
> > > -- leif
> > >
> > >
> > >
> > I think this is going in the wrong direction, personally. I don't like
> how
> > we currently merge master into a dev branch to make a dev release. I feel
> > like master and dev should be synonymous.
>
> I never quite understood why Leif felt the need to create a (temporary)
> -dev release branch. (but then I'm only starting to comprehend git)
>
> > I don't think we've gotten enough testing on dev releases in the past,
> but
> > I think that is changing now. I think we are close to achieving critical
> > mass as far as participation goes. And I think that would only improve if
> > dev and master were closer.
> >
> > As far as backporting goes, I think we should keep that to a minimum. We
> > shouldn't be putting in new features. Only major bugs and security fixes.
> > If people are longing for new features that are in the current stable
> > release then we should be doing stable releases more often.
>
> That's the way I've been handling it so far, and whoever follows me
> as RM I hope does the same.
>
> > And as far as stable releases go I think we should do a little more
> > planning. Much like we were able to do at the summit in Denver. Lets plan
> > out what new features we think we can reasonably get into a release with
> a
> > targetted time frame, but not let time dictate our releases. We should
> have
> > a roadmap available for our users. Lets just agree to have annual or
> > bi-annual summits to hash this stuff out.
> >
> > Within those parameters I think it would be easiest to not have dev
> > branches at all, and just put dev release tags on master. Then when we
> feel
> > we have met our feature requirements for a release (and feel free to add
> or
> > subtract as things move along during the cycle) then we branch a stable
> > branch and then do stabilzation on that branch until we feel it's ready
> for
> > the first stable release. New development can happen concurrently on
> > master, but ideally we'd focus on stabilizing the release branch for the
> > upcoming stable release.
> >
> > I think 4 releases a year is too much from a testing/deployment
> perspective
> > for software of this nature. 1 a year is maybe too little from a
> > features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3
> times
> > a year seems reasonable to me. Probably closer to 2.
>
> really? even two seems too much to me, but maybe growing up with httpd
> I'm thinking too conservatively.
>
>
I think we'd need to find the sweet spot. I think waiting too long people
start complaining about not having feature X available in a stable release
yet. Maybe we need to start with 2-3 a year then in a couple years settle
out at 1 a year. I think right now there's so much to be done that we could
sustain 2/year without a problem.
In fact if there was some hybrid proposal that started off faster and
looser and came into something stricter I might be able to get behind that.
I just don't feel like I can +1 something that I don't see working long
term.
> > When we want to break some major compatibility like on disk format of the
> > cache (assuming we haven't gotten to some plugable model that negates
> this)
> > we would bump the major version, ie 3.x to 4.x. Definitely not more than
> > once a year, but probably more like once every 2+ years. I think we just
> > need to roadmap out those changes appropriately.
> >
> > Sorry, this is a bit of a stream of consciousness but I was trying to
> > adjust my response as this thread grew.
> >
>
> i
>
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.galic@brainsware.org
> URL: http://brainsware.org/
> GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
>
>
Re: [PROPOSAL] New release process
Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 12, 2013, at 3:40 PM, Igor Galić <i....@brainsware.org> wrote
>
>
> ----- Original Message -----
>> On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>>> e currently merge master into a dev branch to make a dev release. I feel
>> like master and dev should be synonymous.
>
> I never quite understood why Leif felt the need to create a (temporary)
> -dev release branch. (but then I'm only starting to comprehend git)
That was a mistake. However, the 3.3.x branch had a real purpose for my RM'ing, just as the "4.x" branch in the WIki propopsal:
Imagine that you are making a release out of Master. You "git pull" it, look at the changes (hopefully), make some tests, build it, etc., maybe fix a bug or two. In the mean time, Phil commits 100 changes to master. What do you tag now for your release?
Granted you can tag as soon as you start your process, and as you make changes, fixes or whatever, you retag accordingly. The 3.3.x branch was made to make this process easier.
To be honest, I don't care about this at all. The 3.3.x branch was a tool to make my life easier, if other RMs have better tools or other methodologies, by all means, use those. Neither of the proposals or changes depend on this, and I hope we can avoid getting hung up on technicalities on how git works ;).
>
>> Ifor software of this nature. 1 a year is maybe too little from a
>> features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3 times
>> a year seems reasonable to me. Probably closer to 2.
>
> really? even two seems too much to me, but maybe growing up with httpd
> I'm thinking too conservatively.
Fwiw, we had these discussions early on, and the general consensus was the releasing early and often was the way to go. We can change that, it's what a healthy community is all about. Fwiw, HTTPD releases fairly often: 25 releases of v2.2 and already 6 releases for v2.4. The latter is roughly 4 releases per year (2.4.0 was released early 2012, right ?). What I think HTTPD did different was very long times between major relies (v2.2 to v2.4).
Cheers,
-- leif
Re: [PROPOSAL] New release process
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> > Hi all,
> >
> > I started a wiki with some ideas on how to streamline and simplify the
> > release process:
> >
> >
> > https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
> >
> >
> > I'd like to start the discussion on this, and come to a consensus before
> > next stable release. One key decision here is what the next stable release
> > should be versioned (I'm suggesting we make it v4.0, with no micro
> > version). The alternative is to keep it as we had planned, which would be
> > v3.4.0.
> >
> > Please discuss, and lets make the updates to that doc as appropriate.
> > Also, if the consensus is to leave the release process as is, we should
> > make that decision as well in the next 2 weeks.
> >
> > Cheers,
> >
> > -- leif
> >
> >
> >
> I think this is going in the wrong direction, personally. I don't like how
> we currently merge master into a dev branch to make a dev release. I feel
> like master and dev should be synonymous.
I never quite understood why Leif felt the need to create a (temporary)
-dev release branch. (but then I'm only starting to comprehend git)
> I don't think we've gotten enough testing on dev releases in the past, but
> I think that is changing now. I think we are close to achieving critical
> mass as far as participation goes. And I think that would only improve if
> dev and master were closer.
>
> As far as backporting goes, I think we should keep that to a minimum. We
> shouldn't be putting in new features. Only major bugs and security fixes.
> If people are longing for new features that are in the current stable
> release then we should be doing stable releases more often.
That's the way I've been handling it so far, and whoever follows me
as RM I hope does the same.
> And as far as stable releases go I think we should do a little more
> planning. Much like we were able to do at the summit in Denver. Lets plan
> out what new features we think we can reasonably get into a release with a
> targetted time frame, but not let time dictate our releases. We should have
> a roadmap available for our users. Lets just agree to have annual or
> bi-annual summits to hash this stuff out.
>
> Within those parameters I think it would be easiest to not have dev
> branches at all, and just put dev release tags on master. Then when we feel
> we have met our feature requirements for a release (and feel free to add or
> subtract as things move along during the cycle) then we branch a stable
> branch and then do stabilzation on that branch until we feel it's ready for
> the first stable release. New development can happen concurrently on
> master, but ideally we'd focus on stabilizing the release branch for the
> upcoming stable release.
>
> I think 4 releases a year is too much from a testing/deployment perspective
> for software of this nature. 1 a year is maybe too little from a
> features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3 times
> a year seems reasonable to me. Probably closer to 2.
really? even two seems too much to me, but maybe growing up with httpd
I'm thinking too conservatively.
> When we want to break some major compatibility like on disk format of the
> cache (assuming we haven't gotten to some plugable model that negates this)
> we would bump the major version, ie 3.x to 4.x. Definitely not more than
> once a year, but probably more like once every 2+ years. I think we just
> need to roadmap out those changes appropriately.
>
> Sorry, this is a bit of a stream of consciousness but I was trying to
> adjust my response as this thread grew.
>
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [PROPOSAL] New release process
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> > Hi all,
> >
> > I started a wiki with some ideas on how to streamline and simplify the
> > release process:
> >
> >
> > https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
> >
> >
> > I'd like to start the discussion on this, and come to a consensus before
> > next stable release. One key decision here is what the next stable release
> > should be versioned (I'm suggesting we make it v4.0, with no micro
> > version). The alternative is to keep it as we had planned, which would be
> > v3.4.0.
> >
> > Please discuss, and lets make the updates to that doc as appropriate.
> > Also, if the consensus is to leave the release process as is, we should
> > make that decision as well in the next 2 weeks.
> >
> > Cheers,
> >
> > -- leif
> >
> >
> >
> I think this is going in the wrong direction, personally. I don't like how
> we currently merge master into a dev branch to make a dev release. I feel
> like master and dev should be synonymous.
I never quite understood why Leif felt the need to create a (temporary)
-dev release branch. (but then I'm only starting to comprehend git)
> I don't think we've gotten enough testing on dev releases in the past, but
> I think that is changing now. I think we are close to achieving critical
> mass as far as participation goes. And I think that would only improve if
> dev and master were closer.
>
> As far as backporting goes, I think we should keep that to a minimum. We
> shouldn't be putting in new features. Only major bugs and security fixes.
> If people are longing for new features that are in the current stable
> release then we should be doing stable releases more often.
That's the way I've been handling it so far, and whoever follows me
as RM I hope does the same.
> And as far as stable releases go I think we should do a little more
> planning. Much like we were able to do at the summit in Denver. Lets plan
> out what new features we think we can reasonably get into a release with a
> targetted time frame, but not let time dictate our releases. We should have
> a roadmap available for our users. Lets just agree to have annual or
> bi-annual summits to hash this stuff out.
>
> Within those parameters I think it would be easiest to not have dev
> branches at all, and just put dev release tags on master. Then when we feel
> we have met our feature requirements for a release (and feel free to add or
> subtract as things move along during the cycle) then we branch a stable
> branch and then do stabilzation on that branch until we feel it's ready for
> the first stable release. New development can happen concurrently on
> master, but ideally we'd focus on stabilizing the release branch for the
> upcoming stable release.
>
> I think 4 releases a year is too much from a testing/deployment perspective
> for software of this nature. 1 a year is maybe too little from a
> features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3 times
> a year seems reasonable to me. Probably closer to 2.
really? even two seems too much to me, but maybe growing up with httpd
I'm thinking too conservatively.
> When we want to break some major compatibility like on disk format of the
> cache (assuming we haven't gotten to some plugable model that negates this)
> we would bump the major version, ie 3.x to 4.x. Definitely not more than
> once a year, but probably more like once every 2+ years. I think we just
> need to roadmap out those changes appropriately.
>
> Sorry, this is a bit of a stream of consciousness but I was trying to
> adjust my response as this thread grew.
>
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [PROPOSAL] New release process
Posted by Phil Sorber <ph...@sorber.net>.
On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
> Hi all,
>
> I started a wiki with some ideas on how to streamline and simplify the
> release process:
>
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
>
> I'd like to start the discussion on this, and come to a consensus before
> next stable release. One key decision here is what the next stable release
> should be versioned (I'm suggesting we make it v4.0, with no micro
> version). The alternative is to keep it as we had planned, which would be
> v3.4.0.
>
> Please discuss, and lets make the updates to that doc as appropriate.
> Also, if the consensus is to leave the release process as is, we should
> make that decision as well in the next 2 weeks.
>
> Cheers,
>
> -- leif
>
>
>
I think this is going in the wrong direction, personally. I don't like how
we currently merge master into a dev branch to make a dev release. I feel
like master and dev should be synonymous.
I don't think we've gotten enough testing on dev releases in the past, but
I think that is changing now. I think we are close to achieving critical
mass as far as participation goes. And I think that would only improve if
dev and master were closer.
As far as backporting goes, I think we should keep that to a minimum. We
shouldn't be putting in new features. Only major bugs and security fixes.
If people are longing for new features that are in the current stable
release then we should be doing stable releases more often.
And as far as stable releases go I think we should do a little more
planning. Much like we were able to do at the summit in Denver. Lets plan
out what new features we think we can reasonably get into a release with a
targetted time frame, but not let time dictate our releases. We should have
a roadmap available for our users. Lets just agree to have annual or
bi-annual summits to hash this stuff out.
Within those parameters I think it would be easiest to not have dev
branches at all, and just put dev release tags on master. Then when we feel
we have met our feature requirements for a release (and feel free to add or
subtract as things move along during the cycle) then we branch a stable
branch and then do stabilzation on that branch until we feel it's ready for
the first stable release. New development can happen concurrently on
master, but ideally we'd focus on stabilizing the release branch for the
upcoming stable release.
I think 4 releases a year is too much from a testing/deployment perspective
for software of this nature. 1 a year is maybe too little from a
features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3 times
a year seems reasonable to me. Probably closer to 2.
When we want to break some major compatibility like on disk format of the
cache (assuming we haven't gotten to some plugable model that negates this)
we would bump the major version, ie 3.x to 4.x. Definitely not more than
once a year, but probably more like once every 2+ years. I think we just
need to roadmap out those changes appropriately.
Sorry, this is a bit of a stream of consciousness but I was trying to
adjust my response as this thread grew.
Re: [PROPOSAL] New release process
Posted by James Peach <jp...@apache.org>.
On Aug 10, 2013, at 4:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
> Hi all,
>
> I started a wiki with some ideas on how to streamline and simplify the release process:
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
>
> I'd like to start the discussion on this, and come to a consensus before next stable release. One key decision here is what the next stable release should be versioned (I'm suggesting we make it v4.0, with no micro version). The alternative is to keep it as we had planned, which would be v3.4.0.
>
> Please discuss, and lets make the updates to that doc as appropriate. Also, if the consensus is to leave the release process as is, we should make that decision as well in the next 2 weeks.
I'm going to ramble a bit here ....
The most successful release process I've been a part of was the IRIX release process. We released every 3 months like clockwork. Every release was guaranteed to be forwards and backwards compatible with the previous releases. That strong guarantee is what allows the rapid release cycle to work, because people have confidence that upgrading will not be an unpleasant experience.
I'm generally in favour of having a single release train that we push regularly. Every three months seems like a reasonable time frame, given the amount of work involved in packaging, deployment and release management. The key to making this work is to prove that we can deliver a strong compatibility guarantee. In order to make a strong compatibility guarantee, we need to make sure that master is always in a releasable state, that we always provide correct configuration upgrade tools, never regress performance, etc. Do we currently have sufficient test and performance coverage to be comfortable that we can do that?
We would also need to define a support period, and be prepared to support all the releases within that period. This might interact poorly with Linux distributions, many of which will have longer release cycles. OTOH, if we can do compatibility correctly, maybe they would feel comfortable shipping the latest release in point updates ...
J
Re: [PROPOSAL] New release process
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> Hi all,
>
> I started a wiki with some ideas on how to streamline and simplify the
> release process:
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
I'd like to address the contents of the wiki as they stand now
(2013-08-12T21:41+0000).
#1) I do *not* like the idea of master being RTC. I have no time to
flesh out a deep technical consideration for a veto (-1), so I'll
leave it as an expression of dislike, phrasing it as an opinion:
Unless we actually declare some other branch the development branch,
master should stay CTR. Even if we directly use master as the -dev
release branch, all that we have to do is make sure it compiles.
It *is* a -dev release after all, and it should be easy and as simple
as git tag -s 3.3.6 to release a new -dev release.
#2) I like the idea of getting rid of the odd/even releases.
Even though I am very fond of them :) -- I see how they reduce our
exposure to an audience that will actually test an upcoming release.
Having very small, incremental changes instead makes for much
smoother upgrades, but I'm with James on this one, that we SHOULD
provide tools for those upgrades. I'm think of it as DB schema
migrations in Rails or something like that. And at least for
the Configuration, I imagine this to go down easier once we have
one configuration format to rule them all.
#3) I'm not very fond of the idea of getting rid of patch-releases
though. To me this and many other points on this list seem like
we're working around our poor tools - or rather, working around
the poor way we're using those tools.
Those are my opinions, if you don't like them, I have others,
but I guarantee, you'll like those even less.
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [PROPOSAL] New release process
Posted by Phil Sorber <so...@apache.org>.
On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
> Hi all,
>
> I started a wiki with some ideas on how to streamline and simplify the
> release process:
>
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
>
> I'd like to start the discussion on this, and come to a consensus before
> next stable release. One key decision here is what the next stable release
> should be versioned (I'm suggesting we make it v4.0, with no micro
> version). The alternative is to keep it as we had planned, which would be
> v3.4.0.
>
> Please discuss, and lets make the updates to that doc as appropriate.
> Also, if the consensus is to leave the release process as is, we should
> make that decision as well in the next 2 weeks.
>
> Cheers,
>
> -- leif
>
>
>
I think this is going in the wrong direction, personally. I don't like how
we currently merge master into a dev branch to make a dev release. I feel
like master and dev should be synonymous.
I don't think we've gotten enough testing on dev releases in the past, but
I think that is changing now. I think we are close to achieving critical
mass as far as participation goes. And I think that would only improve if
dev and master were closer.
As far as backporting goes, I think we should keep that to a minimum. We
shouldn't be putting in new features. Only major bugs and security fixes.
If people are longing for new features that are in the current stable
release then we should be doing stable releases more often.
And as far as stable releases go I think we should do a little more
planning. Much like we were able to do at the summit in Denver. Lets plan
out what new features we think we can reasonably get into a release with a
targetted time frame, but not let time dictate our releases. We should have
a roadmap available for our users. Lets just agree to have annual or
bi-annual summits to hash this stuff out.
Within those parameters I think it would be easiest to not have dev
branches at all, and just put dev release tags on master. Then when we feel
we have met our feature requirements for a release (and feel free to add or
subtract as things move along during the cycle) then we branch a stable
branch and then do stabilzation on that branch until we feel it's ready for
the first stable release. New development can happen concurrently on
master, but ideally we'd focus on stabilizing the release branch for the
upcoming stable release.
I think 4 releases a year is too much from a testing/deployment perspective
for software of this nature. 1 a year is maybe too little from a
features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3 times
a year seems reasonable to me. Probably closer to 2.
When we want to break some major compatibility like on disk format of the
cache (assuming we haven't gotten to some plugable model that negates this)
we would bump the major version, ie 3.x to 4.x. Definitely not more than
once a year, but probably more like once every 2+ years. I think we just
need to roadmap out those changes appropriately.
Sorry, this is a bit of a stream of consciousness but I was trying to
adjust my response as this thread grew.
Re: [PROPOSAL] New release process
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> Hi all,
>
> I started a wiki with some ideas on how to streamline and simplify the
> release process:
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
I'd like to address the contents of the wiki as they stand now
(2013-08-12T21:41+0000).
#1) I do *not* like the idea of master being RTC. I have no time to
flesh out a deep technical consideration for a veto (-1), so I'll
leave it as an expression of dislike, phrasing it as an opinion:
Unless we actually declare some other branch the development branch,
master should stay CTR. Even if we directly use master as the -dev
release branch, all that we have to do is make sure it compiles.
It *is* a -dev release after all, and it should be easy and as simple
as git tag -s 3.3.6 to release a new -dev release.
#2) I like the idea of getting rid of the odd/even releases.
Even though I am very fond of them :) -- I see how they reduce our
exposure to an audience that will actually test an upcoming release.
Having very small, incremental changes instead makes for much
smoother upgrades, but I'm with James on this one, that we SHOULD
provide tools for those upgrades. I'm think of it as DB schema
migrations in Rails or something like that. And at least for
the Configuration, I imagine this to go down easier once we have
one configuration format to rule them all.
#3) I'm not very fond of the idea of getting rid of patch-releases
though. To me this and many other points on this list seem like
we're working around our poor tools - or rather, working around
the poor way we're using those tools.
Those are my opinions, if you don't like them, I have others,
but I guarantee, you'll like those even less.
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: [PROPOSAL] New release process
Posted by Phil Sorber <so...@apache.org>.
On Sat, Aug 10, 2013 at 5:13 PM, Leif Hedstrom <zw...@apache.org> wrote:
> Hi all,
>
> I started a wiki with some ideas on how to streamline and simplify the
> release process:
>
>
> https://cwiki.apache.org/confluence/display/TS/New+Release+Processes
>
>
> I'd like to start the discussion on this, and come to a consensus before
> next stable release. One key decision here is what the next stable release
> should be versioned (I'm suggesting we make it v4.0, with no micro
> version). The alternative is to keep it as we had planned, which would be
> v3.4.0.
>
> Please discuss, and lets make the updates to that doc as appropriate.
> Also, if the consensus is to leave the release process as is, we should
> make that decision as well in the next 2 weeks.
>
> Cheers,
>
> -- leif
>
>
>
I think this is going in the wrong direction, personally. I don't like how
we currently merge master into a dev branch to make a dev release. I feel
like master and dev should be synonymous.
I don't think we've gotten enough testing on dev releases in the past, but
I think that is changing now. I think we are close to achieving critical
mass as far as participation goes. And I think that would only improve if
dev and master were closer.
As far as backporting goes, I think we should keep that to a minimum. We
shouldn't be putting in new features. Only major bugs and security fixes.
If people are longing for new features that are in the current stable
release then we should be doing stable releases more often.
And as far as stable releases go I think we should do a little more
planning. Much like we were able to do at the summit in Denver. Lets plan
out what new features we think we can reasonably get into a release with a
targetted time frame, but not let time dictate our releases. We should have
a roadmap available for our users. Lets just agree to have annual or
bi-annual summits to hash this stuff out.
Within those parameters I think it would be easiest to not have dev
branches at all, and just put dev release tags on master. Then when we feel
we have met our feature requirements for a release (and feel free to add or
subtract as things move along during the cycle) then we branch a stable
branch and then do stabilzation on that branch until we feel it's ready for
the first stable release. New development can happen concurrently on
master, but ideally we'd focus on stabilizing the release branch for the
upcoming stable release.
I think 4 releases a year is too much from a testing/deployment perspective
for software of this nature. 1 a year is maybe too little from a
features/progress standpoint. Doing a minor (3.4 to 3.6) bump 2 or 3 times
a year seems reasonable to me. Probably closer to 2.
When we want to break some major compatibility like on disk format of the
cache (assuming we haven't gotten to some plugable model that negates this)
we would bump the major version, ie 3.x to 4.x. Definitely not more than
once a year, but probably more like once every 2+ years. I think we just
need to roadmap out those changes appropriately.
Sorry, this is a bit of a stream of consciousness but I was trying to
adjust my response as this thread grew.