Xfce development and release model

[Nick Schermer]

2009/5/28 Brian J. Tarricone <bjt23 at cornell.edu>:
> On 05/28/2009 02:33 AM, Nick Schermer wrote:
>>
>> Few notes/questions:
>>
>> - In the branch image there is 'No change', looks a bit weird. You can
>> still commit bugfixes and translations in master while working in a
>> feature branch right?
>
> That raises another question: do we have (or want to have) a bugfix policy
> during development cycles?  Should:
>
> 1. Bugfixes first be checked into master, and then be pushed out to the
> xfce-x.y branch after testing?  (Only viable if master hasn't diverged too
> much from xfce-x.y.)

I'd prefer this, commit in master test it a bit (buildbot) and then
cherrypick into the stable branch. (Ofcourse only if the bug applies
to master, code could have changed in master by a feature branch).

>> - There is, 'The release team always picks the latest available
>> development release of each component for pre-releases and the final
>> release', should be latest stable release I guess?
>
> No, I think that's right... we're talking about gearing up for a new
> xfce-x.y.0 feature release.  The pre-releases for that should come from
> devel releases (which are made from master), since that's what will get
> released as xfce-x.y.0 final.

But a maintainer is also allowed to do independent releases, so assume
I'm releasing a devel version of the panel for a new experimental
feature that needs testing, then I don't want that to show up in the
pre or final release.

>> - I'm not really a fan of the ELS branch, personally I would prefer a
>> small period after the final tag where only bugfixes and translation
>> updates are allowed, like we did with Xfce 4.6.0 ->  4.6.1, then create
>> a stable branch from the 4.6.1 master.
>
> Well that's something else entirely...  what you propose is to do away with
> the code freeze entirely.  The idea of ELS is to collect bug fixes while
> master is in code freeze.

O yeah sorry, misreading. I now get the code-freeze thing.

Nick