[dev] Horde release cycle

[Gunnar Wrobel]

Zitat von Michael Rubinsky <mrubinsk at horde.org>:

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

I fully agree with Micheal here but I assume Jan wanted pretty much  
the same thing. If we really consider an urgent bug fix necessary then  
it will be done in between. Other than that waiting half a year is  
absolutely fine.

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

It should be no problem to track this in the package.xml file.

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

I would say we are not going to use the same major version across all  
libraries. Each library has it own needs when it comes to backward  
compatibility. We would change the major version of a library once it  
breaks BC. All our dependencies would probably need to be declared  
like this:

    <package>
     <name>Exception</name>
     <channel>pear.horde.org</channel>
     <min>1.0.0</min>
     <max>2.0.0</max>
     <exclude>2.0.0</exclude>
    </package>

I don't see "full framework releases" in the current sense anymore.  
Nothing would prevent us however from providing a tar archive or phar  
of a PEAR environment populated with the framework packages and the  
horde base install - though that one is no more than a PEAR package  
itself.

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

Breaking BC in a library might not require a major version bump in all  
applications. It depends a bit on how the dependency to the package  
looks like. The applications will get most of their dependencies  
delivered via the central injector instance in Core. So assuming the  
application uses no strict type hinting on an interface that is  
delivered by the dependency and breaking BC now it might simply be  
possible to use a wrapper within core to handle the break. Of course  
the application might also be able to check what the version of the  
interface is or if a specific method is available.

But I think this already matches our current procedures - with the  
exception of the injection which might make such things easier.

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

I would assume those usually see joined releases.

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

I do agree.

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


                 04/11 10/11 04/12 10/12 04/13 10/13

FRAMEWORK_4_0   --bug---sec-|
                 |
FRAMEWORK_4_1   |     --bug---sec-|
                 |     |
FRAMEWORK_5     |     |     --bug---sec-|
                 |     |     |
FRAMEWORK_6     |     |     |     --bug---sec-|
                 |     |     |     |
master         ---dev---dev---dev---dev---dev----------------------


As far as I understood our discussion above we all agree on having a  
six month release cycle. Every six months there will be a release of a  
new major or minor version. As far as I can see - and I depicted my  
current understanding in the small graphic above - this would mean  
that each release would have a support window of one year.

I don't see that as a problem as long as we are talking about minor  
versions. Assuming the picture above would not list "FRAMEWORK_5" and  
"FRAMEWORK_6" but "FRAMEWORK_4_2" and "FRAMEWORK_4_3" instead: Then  
the "Horde4" branch is suddenly supported over two and a half years.  
Maybe more in case the major version doesn't change.

But what if we break BC frequently? There are people out there that  
code Horde based application - in fact this is what we target. If  
those applications would only get a guarantee of 1 year before major  
work might be necessary that feels like it is not enough.

Following this reasoning I would say we should really avoid breaking  
BC ... in fact ... wasn't Horde3 a good model? ;)

Joking aside: I feel this is the critical point that we need to solve.  
Is there a model that allows us to provide both the users as well as  
the developers - custom app devs and us alike - to have a reliable  
scheme that suits the specific needs of our project?

>
>>>>> 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 :)

Okay, okay ;)

Cheers,

Gunnar

>
> mike
>
> The Horde Project (www.horde.org)
> mrubinsk at 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