Versioning of Frameworks

[Kevin Ottens]

Hello,

On Tuesday 12 May 2015 09:22:12 David Faure wrote:
> On Monday 11 May 2015 15:51:20 Christian Mollekopf wrote:
> > I think there are two possibilities:
> > * "master" is the development branch and we have a separate "release"
> > branch
> > => contributors have it easier because that is perhaps more common,
> > and the people releasing need to know that they shouldn't release off
> > "master" but off "release"
> > * "master" is the release branch and we have a separate development
> > branch
> 
> Neither of those is how development works in Frameworks.
> 
> "master" is the development branch *and* the release branch.
> 
> Most of the work on any library can be split into small enough chunks that
> can be committed incrementally, each change being stable and tested.
> Only very large refactorings (e.g. changing the underlying technology) might
> sometimes require a work branch, but that is really the exception, smaller
> refactorings can also be done incrementally.

I know I'm late to the party, but I'd just like to express my support on that. 
It was a deliberate choice to have such a setup in Frameworks, and it's 
important for the sake of contributions that we don't end up with different 
rules per framework.

Regarding master as both the development branch and the release branch, its 
aim is to push people to discover unwanted interactions early by creating 
friction. It'd be senseless used alone. But, if it's combined with reviews and 
automated tests (ideally TDD but we're still not there yet I'm afraid), then 
it leads to introducing features in baby steps (because you want to avoid 
large useless reviews) with a higher quality. It means you can release any 
time[+].

At least, since we've put that in place in KDE Frameworks, the work keeps 
coming in with a higher quality than before[++] and the releases are "boring". 
And I mean that in a good way: the release notes are small, it's not a drama 
anymore to get everyone aligned, no one tries to rush something under the 
radar to make it to the next release and the generation of the release is 
mostly automated. It doesn't make for a big PR splash but that's OK in my 
opinion, especially for KDE Frameworks.

Also note that if you get your features by baby steps properly and use either 
branch by abstraction[*] or feature toggle[**] techniques (those tend to take 
the form of semi-private/experimental APIs in some of our frameworks) then the 
whole versioning discussion of this thread is much less relevant as well (it's 
not as scary anymore to upgrade dependencies of a framework).

Regards.

[+] http://c2.com/cgi/wiki?ReleaseEasyReleaseOften
[++] Even if I bitch and moan regularly about tests and still think it could 
be better, it be dishonest to not notice there's more peer review and tests 
than before.
[*] http://martinfowler.com/bliki/BranchByAbstraction.html
[**] http://martinfowler.com/bliki/FeatureToggle.html
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150514/42b44799/attachment.sig>