[dev] Horde release cycle

Tue Jan 25 21:45:43 UTC 2011

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.

>>>   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.

>>> 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.

>>> 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.

>> 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.

>>> 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.

>>> 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.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/