Hi,
These days I'm in a client site and really busy with my daytime job
and I don't think I can release Woden myself until mid December , It
would be great if any one else willing to be a RM for Woden this time.
Since last few months Woden code base is stable and ready for next
release, I was st
hi,
I think the actual blocker for Axis2 1.6 release is woden release.
We need to find a way to have the woden release.
thanks,
Amila.
On Mon, Sep 27, 2010 at 4:54 PM, Andreas Veithen
wrote:
> I'm expecting that the proponents of the last minute approach are not
> simply sitting in the peanut g
I'm expecting that the proponents of the last minute approach are not
simply sitting in the peanut gallery, but that one of them is ready to
step forward as a volunteer to do the release using this approach...
Andreas
On Mon, Sep 27, 2010 at 11:25, Samisa Abeysinghe
wrote:
> +1 for creating the
+1 for creating the branch at the last minute.
On Mon, Sep 27, 2010 at 2:50 AM, Deepal jayasinghe wrote:
> I agree with Glen. We should only cut the new branch when we are
> absolutely sure about the release date.
>
> Deepal
> > Hmm. I guess I'm not entirely convinced that we should cut the br
Glen,
I think your point of view is based on a wrong assumption about the
"extra work" caused by branching earlier in the release process.
Assume that we create the branch today and that people just continue
committing to the trunk without taking into account the existence of
the 1.6 branch. If af
Hi Andreas,
On 9/26/2010 5:10 PM, Andreas Veithen wrote:
> First, these guidelines were written at a time when Subversion didn't
> have an effective mechanism to track merges. Second, there is also a
The guidelines were written simply to avoid extra work and therefore the
possibility of skew.
>
I agree with Glen. We should only cut the new branch when we are
absolutely sure about the release date.
Deepal
> Hmm. I guess I'm not entirely convinced that we should cut the branch yet.
> Our general release guidelines [1] are to hold off branching until we're just
> about ready to release
First, these guidelines were written at a time when Subversion didn't
have an effective mechanism to track merges. Second, there is also a
guideline that says that the trunk should "be pointing at SNAPSHOT
versions of all dependencies. This allows for continuous integration
with our partner project
Hmm. I guess I'm not entirely convinced that we should cut the branch yet. Our
general release guidelines [1] are to hold off branching until we're just about
ready to release, to avoid unnecessary merging.
Why not just keep working on the trunk for now, at least until we resolve some
of the i
All,
I'm going to create a branch for the 1.6 release (with the current
HEAD of the trunk as the baseline). The first goal will be to
determine if we need any releases from upstream projects. I'm aware
that there are still ongoing discussions about what should and what
should not go into the 1.6 r
10 matches
Mail list logo
