> How about this, just to define it (more or less what David just said):
> * For development/feature branches, the developer(s) have a responsibility of 
> making sure their code will cleanly merge back into master, either by keeping 
> their branch in sync with master, or by doing any triage at time of merging 
> their branch back to master when ready.
> * The only time CS patches and releases an update for a release is in the 
> event of a security vulnerability. If a vulnerability is found, the CS team 
> will evaluate releases within the last 3 releases, and issue patches where 
> necessary.
> * Otherwise, patches will be applied to the master tree only.
>

I am ok with this in principle. But let me toss another situation and
see what your reaction is.
Let's say we release 5.2.0 on Monday, and on Wednesday, we find an
absolutely horrendous bug that would effect a large number of users.
Would we still wait til 5.3.0 n-months down the road - or release
5.2.1 in a matter of a week(s)?

While I don't like the idea of maintaining multiple releases, there
are occasions where it could make sense.

--David

Reply via email to