myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Schofield <sean.schofi...@gmail.com>
Subject Re: tags, branches and 'current'
Date Fri, 23 Sep 2005 20:41:16 GMT
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 <bdudney@mac.com> 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 <mkienenb@gmail.com> 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 <manfred.geiler@gmail.com> 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 <bdudney@mac.com>:
> >>>>>
> >>>>>
> >>>>>> 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 <mbroekelmann@googlemail.com>
> >>>>>>> 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 <sean.schofield@gmail.com>:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>

Mime
View raw message