Proposed adjustments to our release cycles

[Thomas Lübking]

Am 16.06.2012, 06:25 Uhr, schrieb Scott Kitterman <kde at kitterman.com>:

> On Friday, June 15, 2012 01:05:44 PM Sebastian Kügler wrote:

>> As an example, Frameworks could release updates every 2 months, while  
>> our
>> application collection is updated monthly. New iterations of the  
>> workspaces
>> come every four months. (These numbers are completely arbitrary, and  
>> here
>> only for illustration purpose!)
>>
>> More specifically for the Workspaces, we would like to release all
>> workspaces at the same time.
>>
>> This model would
>>
>> * Allow components to skip releases if they need to take a longer
>> development cycle
>> * encourage developers to have an always releasable master
>> * put more emphasis on continuous integration and other automated  
>> testing

> If I am reading your proposal correctly, I don't see anything about a  
> stable
> supported branch to which only bug fixes were added?  Where is the  
> post-release
> support model in this?

> Perhaps there should be a standard interval (maybe even 6 months) for  
> all of
> KDE SC to have one temporally aligned set of releases to provide  
> post-release
> bugfix support for?  That would allow the more rapid, less synchronized  
> process
> you're advocating, but still give a supported target for distros to aim  
> at.

I don't know whether this is in scope of this discussion, but as developer  
imho we've atm. an issue with release testing.
While there's currently this nice beta testing offensive passing  
relatively much feedback, the current model makes us develop a new version  
for half a year, then have a beta phase only a minority of users  
participate and then dump the new version as "stable" blob.

Therefore i'd -personally- rather use a component wise three branch model:  
current/next/development


CURRENT --------------------

Target audience:
"I know where to turn on my computer"

Commit policy:
* Bug fixes ONLY which are in control and are tested and guaranteed to fix  
bugs.
* NO new features.
* NO experimental fixes.
* NO new strings.

Release policy:
irregular. Whenever developers think it's required to pass a bugfix  
release downstream.
No bloody "patchday"

---------------------------------------

NEXT ----------------------------

Target audience:
"Crashes I fear not, for I have a bash!"

Commit policy:
* Reasonably reliable and finished features
* FINAL API!
* Experimental bug fixes ("I'm quite sure this is gonna fix it, could be  
wrong and have side effects though")
* New strings simply appear untranslated - you've a bash open, you can  
handle this
* NO "NEXT" upstream requirements (ie. eg. Dolphin NEXT must NOT rely on  
KIO NEXT)

Release policy:
Like every two weeks to keep advanced and interested users up-to-date
Of course you can skip releases if there's nothing new to see.

---------------------------------------

DEVELOPMENT ------------

Target audience:
"I produce the crash" ie. component and core developers or whoever thinks  
s/he is

Commit policy:
* in production features
* "it compiles" (usually...)
* ideally code is also reviewed, but that can be component internal policy
* NO "DEVELOPMENT" upstream requirements ("moving target" issue)

Release policy:
git fetch; git rebase

---------------------------------------

In an interval that mostly distros will care about (like every 6 month or  
so) NEXT turns into CURRENT, CURRENT turns into "unmaintained"
At some point ahead (4-6 weeks?), NEXT should rather be frozen for new  
features and focus on becoming in shape for turning into CURRENT (when  
it's also i18n'ized)

I would wish that every distro offers CURRENT and NEXT and that  
distros/variants targeting a more savvy audience would make NEXT default  
and CURRENT option and others promote the existence of NEXT so that their  
advanced users can find and easily select it as replacement.

Cheers,
Thomas