I disagree that we should be committing to tags.
Over time it will get very messy to know what the 1_1_0 was, as an
example having a 1_1_0 tag will help us understand what has changed
between releases, we can diff tag 1_1_0 and 1_1_1, the branch lets us
make changes and keep a 'known' state.
As Martin suggested we need a plan on how we will approach releases.
Proposal;
1) All releases are built as described in the wiki page
2) If a 'show-stopper' (like the faces-config.xml file) are found we
create a branch of the release
3) We fix the bug in both the branch and trunk
4) We commit the branch and push a new release with a tag named after
the release (as in the wiki page)
5) The mainline continues as before
This is basically a small tweak of what is documented on the wiki.
Thoughts?
-bd-
On Sep 23, 2005, at 8:27 AM, Sean Schofield wrote:
The tag definitely will build without the sandbox b/c that is how I
built the release. You need -Dskip.sandbox=True. Or if you use the
bootstrap you just execute the release tag. Now the skip.sandbox
stuff might be part of why faces-config.xml is missing but we can (and
should) fix that part.
Please try this first before creating all sorts of branches, etc. I
will repeat that the tag is basically a branch. You can check into it
so just treat it like a branch. Lets get this fixed with a minimum of
hasty changes to the SVN scheme.
sean
On 9/23/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
Agreed,
We need a branch and we need to edit it.
As I understand it there is currently the
release/ with externals to all the tags except the sandbox.
I've just checked out and the tag won't build because it does not
included sandbox.
My proposal;
1) Create a branch of each subproject that is a copy of the 1_1_0 tag
2) Rework the 'release' to point to the branch of each subproject
3) Create a tag of sandbox starting now that is labeled 1_1_0 (even
though it does not correspond to the 1.1.0 release I'd like the
naming to be consistent) and copy that to a branch
4) Commit the change to the build branch
5) build and test
6) create a new tag in each subproject called 1_1_1
7) send email so that Sean can build and push a new release
Thoughts?
I'm going to start executing in about 15 minutes if I don't hear any
dissent so speak now or hold your peace :-) (for the english not as a
first language folks that is an old Texas colloquialism meaning if
you don't say it now, don't say it)
TTFN,
-bd-
On Sep 23, 2005, at 7:59 AM, Mike Kienenberger wrote:
I'm certainly no expert in making releases nor am I a committer, but
why start off being sloppy? There's a bug that warrants an
immediate
release. There's no guarantee that another such bug won't turn up
after the next release and require another release. That's what
branches are for, so why resist using them?
Because work on MyFaces are ongoing, it's not reasonable to try to
support maintenance releases without branches, is it?
On 9/23/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
Sigh. How did we miss this one? I thought we did a test of
everything? This is probably the only type of error where we could
justify doing this although its kind of embarassing that it
happened
in the first place.
Technically you can check into a tagged version so this is probably
the best thing to do. Let me know when its done (and tested) and I
can do a rebuild and re-publish of the myfaces binary bundles over
the
weekend.
sean
On 9/23/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
We have been discussing doing a release as the problem with the
faces-config.xml missing in the myfaces-all.jar is a very
prominent
one ;)
If there is a way of fixing the existing release with just the
faces-config.xml file, that would be better!
regards,
Martin
On 9/23/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
as long as 1_1_0 is ok to change (by convention tags are not
modified, only branches).
Technically you can change it but SVN (at least Tortoise SVN)
warns
you and says its a tag and you shouldn't. Why do we need a
branch at
this point?
We could create a branch for it but lets establish why this is
necessary first.
All I'm looking for is a place to change the release only
enough to
get the faces-config.xml file in place (as well as the other
missing
bits because that file is not found) and then get a new release
pushed out.
Martin M is planning on doing another release from the trunk
after I
finish my commit. That is fine but risky.
We're doing a release? I haven't read every message on the dev
list
but I must have missed this discussion. What is the
motivation for
this?
TTFN,
-bd-
sean
On Sep 23, 2005, at 5:53 AM, Sean Schofield wrote:
-1
Note that after I tagged the 1.1 release I created a external
in the
"release" dir so if you use
http://svn.apache.org/repos/asf/myfaces/release/1_1_0/ you
will get
"current" but for the release. It doesn't include sandbox so
its not
quite the same but sandbox is not part of the official release.
Doesn't this give you what you need?
sean
On 9/23/05, Martin Marinschek <[EMAIL PROTECTED]>
wrote:
I agree with Martin on this - if you need everything, you can
always
checkout MyFaces, right?
regards,
Martin
On 9/23/05, Martin Cooper <[EMAIL PROTECTED]> wrote:
On Thu, 22 Sep 2005, Bill Dudney wrote:
Well the idea is that people would then be using current/
trunk
to checkout
instead of just current.
But by definition, what's in branches and tags is not
current, so
why does
it make sense to include them under 'current'? The structure
you
described
is exactly what you have without using the 'current'
external in
the first
place, isn't it?
--
Martin Cooper
TTFN,
-bd-
On Sep 22, 2005, at 12:31 PM, Martin Cooper wrote:
On Thu, 22 Sep 2005, Bill Dudney wrote:
Hi All,
I'd like to propose that we change current to be;
current
/branches
/tags
/trunk
Still all externals but tracking the group of tags &
branches
that are
common across all the subprojects.
current/trunk -> becomes what we currently call current
current/branches -> currently empty
current/tags -> 1_1_0 with externals to each subproject's
1_1_0 tag
I would recommend against doing that. It would mean that
everyone checking
out 'current' would end up with multiple copies of the
entire
source tree,
which is unlikely to be something that they would want.
Most people are unlikely to want more than one version
of the
source at any
given time, so I don't see a need to clump together
multiple
versions in a
single checkout.
--
Martin Cooper
To fix the faces-config.xml bug that's been identified in
the
1_1_0
release we can create a branch in current/branches/1_1_0
that
uses
externals to the tags for everything but 'build' which
would
point to the
1_1_0 branch in build (not yet created but I'd be glad
to do
that).
Thoughts?
TTFN,
-bd-
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
