Thanks Sean,
I will be off line for the next 5 or 6 hrs but will check in before
bed time.
TTFN,
-bd-
On Sep 23, 2005, at 2:41 PM, Sean Schofield wrote:
Just checked in a revised build.xml. I will take a look at the
resulting jar files to make sure they look good but I am counting on
the others to help me. The sandbox stuff is defnitely not working but
that is not important at the moment. For now we just need to build
without the sandbox.
I will continue to work on the build so that the sandbox stuff is
built properly so we can merge back down to the trunk when we're done
with all of this.
sean
On 9/23/05, Bill Dudney <[EMAIL PROTECTED]> wrote:
Yes the bug should only be on the trunk and not in the branch.
TTFN,
-bd-
On Sep 23, 2005, at 2:17 PM, Sean Schofield wrote:
The bug is on the trunk though and Bill created the branch off the
release. So this is not a show stopper for 1.1.1. I agree that we
should call it 1.1.1 and Bill is right that we can rename the branch
to whatever we want later.
I'm working on the revised build.xml now. Hopefully we can put
up an
initial RC shortly.
sean
On 9/23/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
Yes, there's a showstopper regression bug in inputCalendar as well.
Still trying to see what revision it broke at, but likely either
289859 -- Martin's revamp on the 17-18th
289189 - Myfaces-569 fix on the 15th
Trying to download and build the revisions right before each to
determine when since it's beyond my abilities to debug javascript.
I'll open a Jira issue once I determine more.
On 9/23/05, Manfred Geiler <[EMAIL PROTECTED]> wrote:
We have the branch created as 1_1_0 (a copy of the 1_1_0 tag) and
once done it can become 1_1_1 or 1_1_0_1 whatever we agree to.
But someone also mentioned that there is a serious bug
(showstopper?)
in jscookmenu.
Therefore my proposal for doing it from current stuff. Or someone
does
fix this as well in the branch?
Hi all,
What is the current problem with jscookmenu, is it a showstopper?
Are there any other (serious) bugs that need immediate fixing?
-Manfred
Agreed that we need to have an RC1 tag (which I'm happy to create
when the vote happens).
Once we agree to release we will create another tag (1_1_1 or
1_1_0_1) and that will become the release tag.
As I said early in this thread I'd prefer 1.1.1 to 1.1.0.1 too.
TTFN,
-bd-
On Sep 23, 2005, at 1:40 PM, Manfred Geiler wrote:
Hi all,
Sorry if I have missed something important, but for lack of
time I
only could rush through this thread. Just my 0.02 on this issue:
- If I got it right, there is only a problem with the myfacse-
all.jar, right?
- So, as someone proposed earlier we could give a workaround
hint
("use the single libs instead") on the homepage, right?
- Therefore no need for too much hurry, IMO
- I would prefer doing a normal "1.1.1 RC1" (instead of 1.1.0.1)
release cancidate from the current source
- I can check against TCK on monday
- After that, we should tag with "1.1.1 RC1" and start voting
on it
- If there are bugs to fix then, we can discuss if it's better
to do a
branch or change current (depending on changes and/or additions
in the
meantime)
WDYT?
-Manfred
2005/9/23, Bill Dudney <[EMAIL PROTECTED]>:
Hi Sean,
I don't mind creating the branches in the same way we have
created
the tags.
I'm glad to create the branches, update the build.xml file run
the
build and put myfaces-all.jar and (tomahawk, api & impl) and
make
sure stuff works there.
I'll call it 1_1_0_1.
TTFN,
-bd-
On Sep 23, 2005, at 9:10 AM, Sean Schofield wrote:
I think we can move past the tag vs. branch discussion now.
I've
conceded a few emails ago that we should do a branch.
I have to go offline for a few hours. Can this wait until a
little
later this afternoon? I can create a branch for us using the
tag as
the starting point.
There is no rush. Rushing is what caused the problem in the
first
place. And yes there was a RC even though it wasn't widely
publicized
it was part of the VOTE thread and was mentioned on the PMC
list.
sean
On 9/23/05, Mathias Brökelmann <[EMAIL PROTECTED]>
wrote:
IMO releasing 1.1.0 was a fast shot.
What I´ve missed where the release candidates which normally
come
before the final release. We should get back to the normal
procedure.
RCs give us the feedback we need to create good releases.
Tags are supposed to be fixed and shouldn´t be changed after
making
one. It would be really confusing if we change the tag 1.1.0
now
and
make a new release number like 1.1.0.1 for it.
I´ve already suggested to make a release branch from
trunk. The
initial branch is the first RC. Each RC has it´s own tag
(svn copy
from the release branch). If someone reports a major bug for
the
RC we
have to fix it in current (trunk) and merge the fix into the
release
branch too. This gives us the chance to commit changes into
current
without affecting the release. A week after the RC we can
vote for
making a new RC or release the final version if remaining
bugs are
trivial.
Tagging and branching with svn is a lot of work (Thanks Sean
for
writing the doc!) But IMO we should automate it. Let us
write a
batch
script or use ant for this stuff.
2005/9/23, Sean Schofield <[EMAIL PROTECTED]>:
We can certainly create a branch but the idea is that we
eventually
have an official release and that's it. Of course there
will be
minor
bugs and those just get fixed in the next release. If you
need
something before then you use the nightly. This is kind
of a
weird
exception.
Even with a branch we need tagged releases and creating
either is
not
exactly trivial because of all of the subprojects. See my
wiki
instructions for an example of what is required
(http://wiki.apache.org/myfaces/Building_a_Release).
Its still not clear to me the difference between svn tags
and
branches
because you can (after ignoring warnings) check into a
tagged
version.
So in this case this is what I suggest we do b/c the
error is
such a
significant one.
Normally I would say we should change the release number,
etc.
and do
an official release (even if its just a minor change) and
maybe we
should consider that in order to avoid confusion (are you
using
the
new or old 1.1.0?)
sean
--
Mathias
