I think we should propose creating that release branch sooner (now?) so we
can minimize unplanned changes slipping into 1.0 and destabilizing it.

-Kirk

On Thursday, September 29, 2016, Anthony Baker <[email protected]> wrote:

> Using the gitflow approach, we cut a release/1.0.0 branch to isolate the
> release branch from ongoing development.  For past releases we have waited
> as long as possible to cut the branch to minimize overhead.  Perhaps this
> time we should create the branch earlier.
>
> JIRA shows the open issues for 1.0.0 [1] but there are some deltas
> compared to the last release scope email [2].
>
> GEODE-17 / GEODE-1570 was mentioned as a possible candidate for 1.0.0 but
> the Fix Version is not set
> GEODE-1168 was not included in the 1.0.0 scope discussions but Fix Version
> is set to 1.0.0
> GEODE-1914 is follow on work from the package namespace changes
>
> @Swapnil, does this accurately reflect the scope discussions for 1.0.0?
> If so, I can update the bugs.
>
> Anthony
>
> [1] https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20GEODE%20AND%20fixVersion%20%3D%201.0.0-incubating%
> 20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
> 20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> [2] http://mail-archives.apache.org/mod_mbox/incubator-geode-
> dev/201609.mbox/%3cCANZq1gBzMTEM_JHzw2YT_LZeC5g472XkNCfJhma76xah=Yyq6A@
> mail.gmail.com%3e
>
>
> > On Sep 29, 2016, at 1:02 PM, Kirk Lund <[email protected] <javascript:;>>
> wrote:
> >
> > What changes are we still waiting on to cut the next RC of Geode 1.0?
> >
> > Is there a way to create a branch for Geode 1.0 develop that allows folks
> > to continue working on post-1.0 features or bug fixes without
> destabilizing
> > Geode 1.0? This way, only the necessary changes for Geode 1.0 would go to
> > the 1.0 branch?
> >
> > -Kirk
>
>

Reply via email to