ant elder wrote:
On 8/9/07, Simon Nash <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote:
[snip]
Simon Nash wrote:
Raymond Feng wrote:
[snip]
2) We could branch for the 1.0 release to contain the candidate
modules
and keep doing 1.0 developement in the branch and merge them into
the
trunk. I'm not sure how feasible it is.
+1
I think it's feasible if "doing 1.0 development" is about stabilizing
the 1.0 release branch, which I guess a release branch is for :) That
means:
- No completely new function, only bug fixes and improvements.
- No changes to dependencies or structure of the distro (unless
required to fix a major bug, and approved by the RM).
- Commits go with a full build of the runtime, itests, samples and
demos, and verification that the samples still work following the
steps documented in their readmes.
How soon would we be moving into this mode? I presume it would be
after
we have released 1.0-beta. Does anyone think it would be sooner than
that?
Simon
I'm probably missing something in your question :). What I'm describing
here is in response to Raymond's question about "doing 1.0 development
in the branch". The branch in question is the 1.0-beta release branch,
used to release 1.0-beta, i.e. *before* it is released.
Sorry about the misunderstanding. I was thinking about 1.0 as being the
release that came after 1.0-beta or whatever we decide to call it.
So while 1.0-beta is being stabilized in the branch, I would expect
development of function targeted at 1.0 ("1.0 development") to be
happening in the trunk.
Simon
I guess thats what I'd expect as well. If we had committers keen to continue
developing post-1.0 function in trunk while we released 0.95 and 1.0 from
the one branch that would be a good approach, but we don't have that so i
think it will be easier to continue with the trunk for 1.0. That would save
a lot of merging and it will keep the 0.95 branch more stable which should
make it easier to get a 0.95 release out.
...ant
Sure, 1.0 development should happen in trunk, but I was trying to
respond to a different point brought up by Raymond.
On Aug 18, we are going to cut the August release branch. The point is
about allowing small changes, bug fixes and improvements to continue in
that branch while we are putting the release distros together, with the
following conditions:
- No completely new function, only bug fixes and improvements.
- No changes to dependencies or structure of the distro (unless required to fix
a major bug, and approved by the RM).
- Commits go with a full build of the runtime, itests, samples and demos, and
verification that the samples still work following the steps documented in
their readmes.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
