Hi, I'm not convinced such a branching strategy will work for us.
The frustrating aspect of "frozen trunk" is also meant to get focus and discipline for everyone to look for a designated period only at stability of your work and to go over the bug tracker. More-over, I prefer to stick to a serious effort to always keep trunk stable, at any time. Only on well defined moments (branch mergers, patch applying) we can accept a really short while of instability. If people do want to continue developing, they can get own branches... or we get this git thing sorted out one day :) What Campbell proposes - to freeze as short as possible - I rather see happen then. This whole 'a' release tradition should go away once too. Somehow we should attempt to get it right once, before a release! One of the ways to solve it is by getting our release team (or the buildbut) to make more often official builds available. Would be easy to at least make a bcon3 build, a bcon4 build, and a release-candidate bfore the final. -Ton- ------------------------------------------------------------------------ Ton Roosendaal Blender Foundation [email protected] www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 29 Jul, 2011, at 9:28, Sergey I. Sharybin wrote: > Hi, > > I'll agree with Campbell. It'll be more convenient for some developers > (for example, me). > > This even can work in such way: > - Trunk is never frozen > - Two weeks before release we create new branch (or replacing branch > from previous release). > - In trunk usual work could happen. > - In that separated branch last changes, fixes, stabilization, blah > blah > happens. > - Some individual fixes can be merged from trunk to that pre-release > branch. > - After release tagging happens based on that pre-release branch. > > It's just idea. > > And about proposal. It can't totally get us free from corrective > releases, imo. Sometimes we're updating libraries and time to time > errors happens when preparing new libraries -- wrong configuration, > wrong compilation flag, forgotten feature to be included. Such things > can be handled by corrective releases, but maybe someone got better > ideas to handle such kind of problems? > > Campbell Barton wrote: >> >> Hi Thomas, This seems good to me, at least - at least we can go ahead >> with it and make minor changes if needed. >> >> I'd like to raise a topic which isn't addressed in you're proposal. >> >> By taking more care to stabilize before release I think we could >> change how we freeze trunk. >> >> Currently we do a release: >> - freeze before release >> - release ahoy >> - platform maintainers get builds made >> - official announcement >> - keep trunk (mostly) frozen for ~1week to see if we need an 'a' >> version >> >> I worry that we take too much time keeping blender frozen since this >> can take approx 3 weeks and with the proposal to do better tested >> releases, this will take longer. >> >> If we need to do an 'a' release individualizer fixes could be applied >> from trunk rather then keeping trunk frozen *just in case* we need to >> do another release (could branch from the tagged rev and merge only >> the fixes from trunk). >> >> I'd like to know what others think about doing a release and >> unfreezing soon after ahoy (1-2 days). >> > > > -- > With best regards, Sergey I. Sharybin > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
