[dev] Horde release cycle

[Michael Rubinsky]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Gunnar Wrobel <wrobel at horde.org>:
>
>>
>> Zitat von Ben Klang <bklang at horde.org>:
>>
>>>>
>>>>
>>>> 1) Breaking backward compatibility is a key issue. It determines  
>>>> how fast the developers may move forward. This in turn also plays  
>>>> a role in how fast new features can be delivered to end users.  
>>>> But backward compatibility also has its part in determining how  
>>>> long a custom Horde application any of you out there wrote will  
>>>> be provided with a supported base.
>>>>
>>>>  So far we have a history of keeping backward compatibility for a  
>>>> very, very long time. But as far as we know most people will  
>>>> upgrade the whole Horde system with every release anyway. So  
>>>> there is no need to be able to run the most recent kronolith  
>>>> release with Horde 3.0.0. Everyone probably uses 3.3.11 anyhow.
>>>
>>> Completely agree here.
>
> I think we are all in the same boat here.

Add one to the boat.


>>>>  A good compromise might be to break backward compatibility every year.
>>>
>>> I'm not sure I'd phrase it quite this way.  Doing development  
>>> eventually means breaking backward compatibility as systems and  
>>> features evolve.  That being said, there's no automatic  
>>> requirement to break backward compatibility when developing so I  
>>> don't think it makes sense to say "we are going to break backward  
>>> compatibility every year."  What is more important to me is the  
>>> promise we make to consumers of our software.   To me the promise  
>>> should be something like this:
>>>
>>> 1) The existing API (method signatures and return values) will not  
>>> change as long as the major number is the same
>>> 2) If new methods or classes (significant functionality) are added  
>>> then a minor number is incremented
>>> 3) When and if we decide to break backward compatibility in a  
>>> given library or application we will commit to supporting the  
>>> latest release of the old major version with security updates for  
>>> a period of time (example: 2 years)
>>> 4) When and if we decide to break backward compatibility we  
>>> document what has changed and, ideally, make recommendations on  
>>> how to update code to support the new version.
>>>
>>> It's bad for everyone if we are requiring frequent  
>>> backward-incompatible changes.  I know that many of us core  
>>> developers feel a lot of strain over the last five years as *no*  
>>> backward incompatible change has been made.  Clearly, with Horde  
>>> 4, we need to move on.
>>>
>>> All of the above applies to the public-facing Framework APIs as  
>>> well as the external-facing Horde application APIs, such as SOAP,  
>>> XML-RPC or any of the DAV implementations.
>>>
>>> With that said, my vote would be that we commit to avoiding any  
>>> backward compatible change for at least 18 months from the first  
>>> release of a new major version.  Forward-incompatible changes,  
>>> such as adding new methods or classes, would be exempt from this.
>>
>> Of course I don't want to force BC breaking changes if they are  
>> unnecessary. I might comment in more detail on this tomorrow but I  
>> wanted to mention that you are looking at this from the users side.  
>> There is also the developers side. An example: I started improving  
>> the Kolab drivers in 2006. Back then Horde3 was the active branch.  
>> The was already some Kolab code in there that desperately needed  
>> some improvements. While I was able to do them I had to bend  
>> backwards to keep BC. I admit that at that point in time my PHP  
>> knowledge was also much worse than now so I produced really crappy  
>> code. However: That code is still there. 2011, stable version. And  
>> that is really not good.
>>
>> Code always needs to work for both sides: users and developers. So  
>> as a developer I want to get the promise: "Yes, you may break BC if  
>> it is bringing you forward. You will have to wait a little until  
>> you get your next window but it will come at a defined time."
>>
>> One year or 18 months wouldn't matter that much to me. But I want  
>> that promise ;)
>
> I agree with you both. :)
> My take is that we should keep using semantic versioning, and only  
> break BC with major versions.
> I'm not sure we really should have a minimum time span between major  
> versions though. We shouldn't break BC needlessly, and we should  
> *decide*, in each case, if we want to break it. But I can live with  
> having a minimum time span if this has more consensus. It shouldn't  
> be too long though, 12 months I could feel comfortable with.

I don't see the need for a minimum wait time for breaking BC. Breaking  
BC isn't something to be done without a lot of thougt.  If BC needs to  
be broken, there is a good reason for it (or we shouldn't be breaking  
it). So, if there is a good enough reason for us to break it, we  
shouldn't be hampered by an arbitrary wait time.


>>>> 2) Applications could be released in a synchronized manner every  
>>>> half year. That would keep us in tune with some of the major  
>>>> Linux distributions out there and might help packagers to deal  
>>>> with the Horde applications. Security releases are a different  
>>>> matter of course.
>>>
>>> This works for me as well.  Again whatever our promise is as far  
>>> as security updates needs to be documented publicly on our website  
>>> somewhere so distributions and packagers know what to expect.
>
> About which releases do we talk here? Minor version releases or  
> bug/security fix releases? IMO this should be feature (minor version  
> releases). We should release bug fixes when we find the time, and  
> security fixes as necessary, both inbetween this regular release  
> schedule.

Agreed, for the most part. Minor/Major feature releases should be done  
at the six month release date. With such a short release cycle,  
however, I don't see the problem with waiting until the next release  
date to push minor, non-security bug fixes. I'm not saying we *never*  
release non-security releases between cycles. Obviously, something  
that could be considered a major issue could be released sooner.

>>>> 3) Does a similar release scheme make sense for framework  
>>>> packages? Maybe not as there are many of these and not all of  
>>>> them will see changes during six months. In addition these are  
>>>> intended to be distributed as small PHP component libraries with  
>>>> Horde4. So it could make sense to publish bug fixes once these  
>>>> become available. But I admit I'd prefer regular releases for  
>>>> these components as well.
>>>
>>> I think there's a difference in Framework packages versus Horde  
>>> packages.  Personally I feel no need to release library packages  
>>> on any regular basis.  For example, the Horde Cache SQL driver  
>>> pretty much does what it needs to and, bugs aside, doesn't need to  
>>> do much more.  My feeling is that it should be updated and  
>>> released only as needed.
> Yes, agreed, the framework packages are completely independent from  
> that and can be released with any small number of fixes, even with  
> only one fix, if we see fit.
> We should use the same versioning scheme for those though.

I'm confused a bit about versioning here, and maybe this is what using  
PEAR will provide us, but: If we release framework packages at will,  
incrementing version numbers each time, then it's going to get very  
difficult to track which versions of what library are required for  
which versions of what application.

Are we going to keep the major version numbers the same across all the  
libraries, and does this also mean that we are no longer going to  
provide a full framework release? We've never really treated them  
separately to this degree before, so I have a few questions about it.  
If we break BC in one library, will that require a major version bump  
to not only all applications, but each individual library as well, or  
will it only be bumped in the case that there was code within that  
needed to be changed due to the BC break? If we don't bump all version  
numbers, how are we going to track what version of what framework  
libraries work (or don't work) together? Is this going to be handled  
by PEAR?

Where does Horde/Core fit into this, is this released as part of "Horde Base"?


>>> Now, when we are talking about releasing Horde and associated  
>>> applications as a package, then I do agree that we need a regular  
>>> release schedule.  My preference would be to make a new minor  
>>> version release every 6 months and a new major version release  
>>> approximately every 18 months.  Whatever changes we have in Git  
>>> when release time comes get tested, polished and documented then  
>>> released as close to the due date as possible.
>
> Ack.

I'm not sure I like this either.  Maybe because I'm so used to the  
release-when-it's-ready mentality we've had for so long, but I don't  
think we should be committing to a major feature release at *any*  
interval. As discussed above, if we need to break BC - and thus bump  
the major version number - we should do so when needed, not wait 18  
months for it. Likewise, it's possible we will go 18 months without  
having to break BC, and won't *need* to bump the major number.

My general idea for releases would be: Every 6 months we roll a  
release for any application that has changes. If those changes cause a  
break in bc, it's a major version bump. If it's non bc-breaking new  
features, it gets a minor bump. Bug fix only? Just a point bump.
In between 6 month cycles, security/critical bug fixes and possibly  
minor framework library releases if needed.

>>>> 4) I would like us to support the active version (which also gets  
>>>> new features), the last stable version (which gets no new  
>>>> features but the bug fixes) and the version before that (which  
>>>> only gets security fixes). If that is the case and assuming we'd  
>>>> keep that scheme when breaking backward compatibility every year  
>>>> then each version would see support for three full years. In case  
>>>> that would not be enough one might consider doing something like  
>>>> the long term support scheme Ubuntu is doing.
>>>>
>>>> 5) With the scheme suggested above we would have four active  
>>>> branches (development, active, stable, security) which might be  
>>>> too much. Three would sound better.
>>>
>>>
>>> #4 and #5: This seems like too much work to me, but I think it is  
>>> more important to get feedback from the community here.   
>>> Personally, I'm fine with only two maintained branches:
>>> 1) The latest current major version release (new features,  
>>> bugfixes and security)
>>> 2) The last release of the previous major version (security and  
>>> critical bugfixes only).
>>>
>>> We will always have a development branch as well of course but no  
>>> guarantees are made at all.
>
> I'm not sure. Wouldn't we release new (minor) versions basically  
> from master? I see it working this way: when we start to polish the  
> next minor release, we branch off master, so that we can keep  
> hacking there with not-to-be-release code while we prepare the  
> release. If there is really some major developement going on that we  
> don't feel should slip into the next release, such development  
> should happen in a topic branch anyway. So master is basically  
> what's going into the next release. If code in master broke BC, we  
> release a new major version, if not, we release a minor version (see  
> above).
> This way we keep 3 active branches, master for the next release, say  
> Horde 5 or 4.2, a security branch e.g FRAMEWORK_4_0, and a bug fix  
> branch, e.g. FRAMEWORK_4_1.
> Only for the (hopefully) very short time span of polishing the  
> release, we have a 4th active branch. This is btw. how we already  
> worked in the past.

I agree with Jan. I like the way we have typically handled this and  
would like to continue in this way.

>>>> In addition to the points above it might also be important what  
>>>> we can actually do with PEAR. Horde4 will be fully PEAR based and  
>>>> hopefully we can rely on the dependency management that comes  
>>>> with PEAR to prevent users from accidentally pulling packages  
>>>> from mismatched branches.
>>>>
>>> Agreed.  This versioning and dependency should also be available  
>>> in any other packaging mechanism we distribute, such as RPM or  
>>> DPKG as appropriate.
>>>
>>>> And last but not least the versioning is important too. Would we  
>>>> do Horde5, Horde6, Horde7...? Or Horde 2011, Horde 2012, Horde  
>>>> 2013? I'm somewhat in favor of the latter.
>>>>
>>> I dislike year-based version numbers.  I'm a fan of Semantic  
>>> Versioning, which is reflected in my comments above:  
>>> http://semver.org/
>
> I'd veto any year version names. Let's stick with sane semantic  
> versioning that users are used from ourselves, from PEAR, PHP, etc.

+1 - Please no yearly version names :)

mike

The Horde Project (www.horde.org)
mrubinsk at horde.org