[dev] Horde release cycle

Tue Jan 25 21:04:07 UTC 2011

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

Cheers,

Gunnar

>
>
>>
>> 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.
>
>>
>> 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.
>
> 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.
>
>>
>> 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.
>
>
>>
>> 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/
>
>
>> As mentioned these are just a few thoughts that come to my mind  
>> when considering the release scheme. I'm certain I forgot a bunch  
>> of important factors but hope we'll touch these in the discussion  
>> that hopefully evolves.
>>
> Thanks for getting the discussion started!
>
> /BAK/
> --
> Ben Klang
> Core Developer
> The Horde Project
> bklang at horde.org
> http://www.horde.org
>
> --
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de