This makes sense to me. Perhaps we should discuss, and document how to best go
about ("no RC") releases?
It seems to me that there are two types of releases: Normal releases and “hot
fix” releases. In the case of a normal release, I think there should be
mechanism built in to encourage people to commit fixes prior to the release.
I’m thinking something like this:
1) There would be a period of time until a release is “frozen”. 72 hours?
Anyone working on something that should go into the release should commit their
work to develop before that time is up.
2) Once the freeze goes into effect, a branch is made for release x.xx for xyz
3) A discussion/VOTE is opened at that point and kept open until the release is
voted through. Any issues discovered should be corrected in the release branch.
If they are applicable to future releases, the change should be applied to
develop as well.
For hot fixes, the last release branch should probably be branched and we
should have an expedited voting process.
Anything else? Are there complications that I’m ignoring/missing?
On Oct 26, 2014, at 11:37 AM, Erik de Bruin <e...@ixsoftware.nl> wrote:
> Justin,
>
> I applaud and would like to promote the new "no-RC" release procedure. I
> encourage all contributors (not only committers/PMC members) to look at the
> mentioned branch (develop) and check it as it were a release candidate!
> This way, if any issues are found, they can be fixed and tested without
> Justin having to call (and cancel) repeated RCs. Which will save all
> involved a lot of time.
>
> A suggestion: why not cut a release branch and have the testers work of
> that? That way development doesn't have to be frozen on 'develop', or -
> lacking a freeze - prevent 'develop' from becoming a moving target during
> testing, when new commits are made. Changes made on the release branch can
> be merged back to into 'develop' even during the release cycle. This is how
> the process was originally envisioned when we made the move to Git [1].
>
> On a personal note: the frequency of the utility releases is too high for
> me to actively participate in any of them while also contributing actual
> code to the project.
>
> EdB
>
> 1: http://nvie.com/posts/a-successful-git-branching-model/
>
>
>
> On Sunday, October 26, 2014, Justin Mclean <jus...@classsoftware.com> wrote:
>
>> Hi,
>>
>> After Squiggly is released I like to release Tour De Flex 1.2. [1] It has
>> a couple of significant improvements including support for 3rd party
>> components and (allmost) all examples now have a cleaner, more consistent
>> look and feel. A couple of Squiggly examples have also been added. [2]
>>
>> Can current committers/PMC members take a look at what currently is in
>> develop and review/point out any issues? If no issue are raised in the next
>> few days I'll make a release candidate and call a vote.
>>
>> If there is anything people would like to see fixed or features added in
>> this release please speak up now.
>>
>> Thanks,
>> Justin
>>
>> 1. https://issues.apache.org/jira/browse/FLEX-34612
>> 2.
>> https://github.com/apache/flex-utilities/blob/develop/TourDeFlex/TourDeFlex3/RELEASE_NOTES
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
