Bill, Why don't you create a new branch then but follow my wiki instructions (replacing 'tags' with 'branches.' I think we should *definitely* skip the sandbox as it is not part of the release. We must get the build working without the sandbox anyways.
You can create a svn external in the "release" dir even though its not yet a release. When we're officially released, we will change this to point to a *tagged* version of that branch. What do you think? sean On 9/23/05, Bill Dudney <[EMAIL PROTECTED]> wrote: > > On Sep 23, 2005, at 8:13 AM, Sean Schofield wrote: > > > 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. > > > > Well agreed partly. Any release has bugs, some have to be fixed some > can wait until the next official release. For bugs that must be fixed > in the existing release we can and should be changing a branch (and > of course applying the same fix to the trunk). The reason this is > important is that some users can't tolerate the risk of being on the > trunk because of the unstable (perceived or true) nature of trunk. > Instead they want to be on a relatively stable branch that is changed > only slightly and only when a 'big' bug is found and fixed. > > This does increase our overhead but I think given the state of the > project (how many users) we need to get to this level of > sophistication. We are also at the state where we really need > automated tests to help us make sure we've not hosed ourselves. I > will try to get some automation done WRT running 'simple' with both > myfaces-all.jar and (myfaces-api.jar, myfaces-impl.jar, and > tomahawk.jar) which should at least prevent problems like this from > sneaking past us. > > > 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). > > > > Yes this is the downside of subprojects & externals. > > > 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. > > > > tags are by convention not commited to but are instead a constant > 'state of the project at a point in time' > branches are used as described earlier > > > 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?) > > I like 1.1.1, or 1.1.0.1 (too long IMO). I'm open though. > > TTFN, > > -bd- > > > > > sean > > > > > > On 9/23/05, Mike Kienenberger <[EMAIL PROTECTED]> 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 > >>>> > >>>> > >>> > >>> > >> > > > >
