Usual process for wicket are to let trunk follow current release, when switching major build number ie from 1.3 -> 1.4 then make a branch for the old version I suggest we do the same..?
And yeah just upgrade the dependencies :) Unless someone disagree. -N 2010/3/23 Boris Goldowsky <bgoldow...@cast.org>: > I think this sounds good, and meshes with the comments several other people > have made. So I think we're converging on a general agreement for a > process. Documenting it on the wiki would be great. > > If there are no objections, I can take the first step in this process, which > would seem to be setting wicketstuff-core's dependency to wicket 1.4.7, and > then asking people to test it. We should probably set a date by which we > ask people to test out the modules they use -- otherwise if no issues are > reported we won't know when to declare the testing period over and actually > do the release. > > How do people feel about the other dependencies in there (jetty, slf4j, > etc)? Should we just as a matter of course re-point those to the latest > stable versions when we do a version bump of wicket and are heading into a > round of testing? > > Bng > > > > Michael O'Cleirigh wrote: >> >> Hello, >> >> I'd like the trunk to follow the latest wicket release since when >> wicketstuff-core is released it is meant to be paired with the current >> wicket release. i.e. not 1.4-SNAPSHOT but 1.4.7, 1.4.8, 1.4.9 and eventually >> into 1.5RC1, etc. >> >> Envisioned Process for 1.4.8 Wicket Release: >> 1. wicket releases new version 1.4.8 >> 2. wicketstuff-core pom is updated for 1.4.8 >> 3. organized testing and vote on release. >> 4. release (non SNAPSHOT) artifacts are generated and pushed into maven >> and a svn:/tags/wicketstuff-core-1.4.8 tag is created >> 5. trunk pom's are changed back to wicketstuff-core version of >> 1.4-SNAPSHOT >> >> I think we should only cut one release per wicket main release and any >> other changes just go automatically into the 1.4-SNAPSHOT releases that are >> generated when a developer commits. If a user needs new features in the gap >> between releases they can just get the SNAPSHOT releases. >> >> +1 for creating a svn:/branches/wicketstuff-core-1.4 when trunk switches >> to the 1.5 RC's. We can then support two release lines but everying is tied >> to wicket main releases. When wicket end of life's the 1.4.x line there >> will be no more releases just snapshots. Also there should be no developer >> requirement to sync the 1.4 and 1.5 branch project contents (i.e. supporting >> two lines) just maintenance on 1.4 branch and new development on trunk. >> >> +1 on creating wicketstuff-core jira to coordinate release process. >> >> +1 on creating a wicketstuff-core/wicketstuff-test module to share testing >> code between core projects. >> >> +1 on running integration tests to find run-time issues before release on >> the generated project artifacts (i.e. like selenium through maven >> integration-test phase). I know this is hard but maybe a special profile in >> the pom to allow these extended quality checks to be run outside of a >> continuous integration environment prior to release. >> >> +1 improving the wicketstuff developer wiki with details on how the >> release process works (I'm volunteering) >> >> Regards, >> >> Mike >> >>> Id vote for this one: >>> >>> modify the trunk >>> first for 1.4.7 fix the incompatibilities if there are, and then release >>> it as 1.4.7 and make trunk to follow 1.4-SNAPSHOT? >>> >>> And if you like sonar, it's opensource and requires almost no setup it >>> has a fluent plugin with maven. For example theres a pretty good >>> integration between hudson, I could'nt find one for team city though >>> :/ But in theory it's just running the mvn command sonar:sonar.. >>> >>> 2010/3/23 Major Péter<majorpe...@sch.bme.hu>: >>> >>>> >>>> Tests are good, but this could be also arranged with voting, or not? >>>> So what would be the best? >>>> Modify the trunk to use 1.4.7, and release the current state as >>>> wicketstuff 1.4.1 (because it's using 1.4.1 now) or modify the trunk >>>> first for 1.4.7 fix the incompatibilities if there are, and then release >>>> it as 1.4.7 and make trunk to follow 1.4-SNAPSHOT? >>>> Or what else do you have in mind? >>>> This sonarsource is good stuff, +1. >>>> >>>> Peter >>>> >>>> 2010-03-23 12:33 keltezéssel, nino martinez wael írta: >>>> >>>>> >>>>> +1 for me on upgrading wicketstuff core to 1.4.7. >>>>> >>>>> On another topic making sure that an upgrade actually works are >>>>> another thing. Code might compile but there could be runtime >>>>> problems.. I discussed looong time ago a possibility for making tests >>>>> for the javascript parts of the code aswell, with rhino... We could'nt >>>>> really call it stable until we made sure it where that. On another >>>>> node I'd suggest adding wicketstuff core to nemo.sonarsource.org , as >>>>> it would help showing code metrics etc.. >>>>> >>>>> 2010/3/23 Stefan Lindner<lind...@visionet.de>: >>>>> >>>>>> >>>>>> Should we really start with a big bang? Support wicketstuff STABLE >>>>>> core releases for Wicket 1.4 AND 1.5RCx? Is a RC for Wicket 1.5 in >>>>>> sight? Or >>>>>> does this mean everything in wicketstuff will stay as it is for a long >>>>>> time? >>>>>> Why not start with a smaller step and create a core wicketstuff >>>>>> release for current wicket 1.4? >>>>>> >>>>>> Stefan >>>>>> >>>>>> -----Ursprüngliche Nachricht----- >>>>>> Von: Major Péter [mailto:majorpe...@sch.bme.hu] >>>>>> Gesendet: Dienstag, 23. März 2010 11:38 >>>>>> An: users@wicket.apache.org >>>>>> Betreff: Re: Wicketstuff versioning >>>>>> >>>>>> 2010-03-23 11:24 keltezéssel, Boris Goldowsky írta: >>>>>> >>>>>>> >>>>>>> I may be wrong, but wouldn't it make sense to delay creating a 1.4.x >>>>>>> branch until/unless someone actually wants to commit some code that >>>>>>> would be different for 1.4.x and 1.5-SNAPSHOT? Once we branch, we >>>>>>> have >>>>>>> to start committing every bug fix to two different versions, right? >>>>>>> >>>>>> >>>>>> Yes, you're right about this, maybe we should wait until the first 1.5 >>>>>> RC with it. >>>>>> >>>>>> >>>>>>> >>>>>>> If we're lucky, everything in Wicketstuff may work fine unchanged >>>>>>> with >>>>>>> 1.4 and 1.5, and I suggest we can save ourselves a large amount of >>>>>>> headache by just maintaining a single trunk, and bumping the version >>>>>>> after there's an official Wicket release. >>>>>>> >>>>>> >>>>>> As far as I saw, there was some major modifications in the core around >>>>>> the request-handling and URL-strategies, so this could rise up some >>>>>> issues. >>>>>> >>>>>> >>>>>>> >>>>>>> Of course, correct me if I'm wrong. I don't know how fundamentally >>>>>>> different wicket 1.5 is going to be, or if there are a lot of people >>>>>>> running snapshots of it now who would need Wicketstuff to be tracking >>>>>>> it. >>>>>>> >>>>>> >>>>>> Is 1.5 RC1 good for everyone? :) >>>>>> >>>>>> Regards, >>>>>> Peter >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
