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
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> >
> >
>
