[TODO] release considerations
hannu.nyman at iki.fi
Fri Jun 3 12:32:40 EDT 2016
On 3.6.2016 19:02, Ted Hess wrote:
> On Fri, 2016-06-03 at 10:34 +0200, John Crispin wrote:
>> * a name
>> - keep the year.month.minor pattern ?
>> - do we want codenames ?
> Prefer YY.MM.mm (codenames are good for development and branch names)
YY.MM might work also as the branch name. We already have packages & Luci
branch names like "for-15.05".
But codenames are also nice, at least short and simple names. Kamikaze and
Backfire were such short and simple names. But Designated Driver, Chaos
Calmer, Barrier Breaker and Attitude Adjustment are too long for casual use,
so in the forum discussions they have usually been referred just as AA, BB,
or AA12.09, BB14.07 etc.
>> * set a ETA
>> - do we want to fork or call for a feature freeze and stabilize in trunk ?
> Branch and release is the best strategy. It keeps the trunk alive for future
> work and easy to merge forward after release. Also, you have a place for maint
> work after release which continues the linear history.
Earlier Openwrt release have had the problem of a rather long time period
between branching and the final release. When the time period grows to 4-6
months, trunk goes too much forward compared to the forthcoming release.
Release starts to look stale. And developers' focus has tended to remain on
trunk development (instead of the boring branch stabilising/finalising work).
Creating new features is much more fun... And backporting those nice new
features to the release branch still before the release would be great...
Branching might work if the period between branching and final release can
been kept short, weeks instead of months.
Same goes also for a feature freeze: it should be kept short.
A combination might also work: 2-3 weeks' feature freeze before the rc
version, and then branching for the rc build. And the final release rather
quickly after that.
More information about the openwrt-adm