flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject Re: New Release Process (was Re: Release 1.2 of Tour De Flex)
Date Sun, 26 Oct 2014 21:41:31 GMT

> I would say that during the “last call”, if nobody speaks up with a plan
> to commit stuff soon that shouldn’t be put into the release, that a
> release branch is optional.

It's easy enough to create a release branch, but merging back into dev and master can sometimes
be painful. I'm not sure what the point is for the utilities as we have many projects in a
single repository and gits inability to handle sub trees simply.

What has happen in the past (on a couple of occasions when working on a SDK release) is people
have checked into the wrong branch which caused some merging issues. Also the automated test
were mostly run on the develop not the release branch which also caused some issues. The simpler
it is the less is likely to it is to cause issues IMO.

Given it's simplicity (and no automated tests) I can't see TDF having any issues along those

>  For TDF, if it is some third-party example, I’d probably say yes.

Third party examples are external and not part of the release.

> I think it would be simpler to open the discussion but not a vote until
> the discussion doesn’t appear to have any release blockers being
> discussed.

+1 The concern I have is that this period could drag on a lot longer than the normal RC cycle
and that people wont check things carefully until a vote is called.

> More than one board member has said that the 72-hour requirement is just a
> guideline

But there needs to be a good reason for it to be shorter, given we are volunteers and are
scattered across the global 72 seems a reasonable amount of time someone cay check and vote
on a release. [1] (last bit in expressing votes).It's rare that we get 3 votes in under 48
hours anyway.


1. http://www.apache.org/foundation/voting.html

View raw message