[dev] Horde release cycle

[Jan Schneider]

Zitat von Gunnar Wrobel <wrobel at horde.org>:

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

Agreed. We never did framework releases in the past either, besides  
the snapshots. It was always Horde Base + Framework. And that wouldn't  
change, if we consider tarball releases still necessary.
Using package version numbers and dependencies should work like Ben explained.

If we are going to build tarball releases utilizing the PEAR  
installer, then we probably need two different package.xml for Horde  
though. One that really only pulls in any dependencies of the base  
Horde package. And another one that pulls in all framework packages.
The rationale is that some framework libraries are only required by  
certain application, e.g. Vcs in Chora. So they would only be  
installed through a dependency in the application's package.xml, if  
installing this app through PEAR. If installing through a tarball, we  
don't have any dependency management, so every library needs to be  
available after installing horde-4.x.y.tar.gz.

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

See above, if releasing tarballs, all framework packages are part of  
the Horde release. If releasing pear packages, this is just another  
library package.

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

Yes, my ack was just for last sentence, not the 18-months-release cycle.

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

So you're even going one step further by not requiring a minor version  
release after 6 months if we didn't add any new features. I can live  
with that too.

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

With our limited resources, I don't think so. We could not break BC,  
sure, but we all agreed we don't want this limitation anymore.

The only solution I see is to add LTS releases to that equation. I  
like the more formal approach of Ubuntu better than the  
randomly-picked-stable-version of Kernel development, which is harder  
to follow.
But I don't see us having the man power for that at the moment. Let's  
he how the release plan works that we're discussing here, and what the  
feedback is. I have no idea how often we are going to break BC in  
reality, how big those BC breaks are to pose a problem for 3rd-party  
developers, and if developers are going to ask for longer version  
support.

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

Jan.

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