Re: Wicketstuff versioning
> Yes, confluence is great, but a bit of useless since the spam-incident. > I think the confluence is still full of with spammer users and > spamcontents. Also the registration doesn't work, but this is an another > issue. Nino, if I remember correctly, you can access confluence, right? > Could you do something with these? Yeah can acess confluence, but there are A LOT of spammer users, and I gave up deleting them last time after using ½ an hour. I think it would be easier using a sql connection and droping the spammer users through there. What are you suggesting? > > Also TeamCity is failing lately, since there is some network error, and > it cannot access the svn (Connection refused). Hmmm we had that problem with bamboo too :/ Im not sure it's the same though.. 2010/3/23 Major Péter : > Hi, > >> +1 on creating wicketstuff-core jira to coordinate release process. > > Here it is: http://wicketstuff.org/jira/secure/Dashboard.jspa > >> +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. > > This testing would be really great, but I think this is more of a dream, > rather then a real purpose right now. The project maintainers are doing > their work in their freetime, making them mandatory to create testcases, > may scare them, because they don't have the time to maintain those too. > >> +1 improving the wicketstuff developer wiki with details on how the >> release process works (I'm volunteering) > > Yes, confluence is great, but a bit of useless since the spam-incident. > I think the confluence is still full of with spammer users and > spamcontents. Also the registration doesn't work, but this is an another > issue. Nino, if I remember correctly, you can access confluence, right? > Could you do something with these? > > Also TeamCity is failing lately, since there is some network error, and > it cannot access the svn (Connection refused). > > Thanks, > 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
Re: Wicketstuff versioning
Hi, > +1 on creating wicketstuff-core jira to coordinate release process. Here it is: http://wicketstuff.org/jira/secure/Dashboard.jspa > +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. This testing would be really great, but I think this is more of a dream, rather then a real purpose right now. The project maintainers are doing their work in their freetime, making them mandatory to create testcases, may scare them, because they don't have the time to maintain those too. > +1 improving the wicketstuff developer wiki with details on how the > release process works (I'm volunteering) Yes, confluence is great, but a bit of useless since the spam-incident. I think the confluence is still full of with spammer users and spamcontents. Also the registration doesn't work, but this is an another issue. Nino, if I remember correctly, you can access confluence, right? Could you do something with these? Also TeamCity is failing lately, since there is some network error, and it cannot access the svn (Connection refused). Thanks, Peter - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff versioning
10-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: >>>>> >>>>>> >>>>>> 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
Re: Wicketstuff versioning
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: 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: 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
Re: Wicketstuff versioning
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: 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: 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 w
Re: Wicketstuff versioning
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 : > 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 : >>> 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
Re: Wicketstuff versioning
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 : >> 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
Re: Wicketstuff versioning
1.5 rc only makes sense if it is not compatible with 1.4 any longer. Otherwise 1.4 makes better sense to me ;) Sent from my iPhone On 23 Mar 2010, at 10:45, Stefan Lindner wrote: 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
Re: Wicketstuff versioning
+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 : > 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
RE: Wicketstuff versioning
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
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
Re: Wicketstuff versioning
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? 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. 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. Bng On Mon, 2010-03-22 at 19:07 +0100, Major Péter wrote: > Yepp, nice chat, but who wants to do the dirty work?? > The first thing would be to create the 1.4.x branch, then release the > current state as wicketstuff 1.4.7, and then modify the settings of the > trunk to compile with wicket trunk. > Let's split these jobs up to people, then do it. > Also maybe we should write some policies about projects and maintaining > the projects (like the current maintainers e-mail address should be > available in the project pom.xml#developers tag, something like that), > but this is an another thread... > > Best Regards, > Peter - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff versioning
Yepp, nice chat, but who wants to do the dirty work?? The first thing would be to create the 1.4.x branch, then release the current state as wicketstuff 1.4.7, and then modify the settings of the trunk to compile with wicket trunk. Let's split these jobs up to people, then do it. Also maybe we should write some policies about projects and maintaining the projects (like the current maintainers e-mail address should be available in the project pom.xml#developers tag, something like that), but this is an another thread... Best Regards, Peter 2010-03-19 15:04 keltezéssel, Boris Goldowsky írta: > nino martinez wael wrote: >> I'll be happy to join in Boris. >> > That would be awesome, thanks Nino. > > I'm thinking the first thing would be to bump the wicket dependency to > v1.4.7 and do a maven release of the current state of wicketstuff-core > as version 1.4.7. Make sense? Is that something you could do? > > Stefan Lindner wrote: >> Perhaps we should define an island of stability (like the name >> wickststuff-core implies). > I agree with that & the rest of your message. Jeremy put together a > nice framework under wicketstuff-core, and there are a decent set of > modules in there. How about calling those the stable set. Anyone can > put something into core - as long as it works and they're willing to > make some effort to keep it working. If one of the core modules breaks > with a future wicket version, and no one steps up to fix it, then it > gets dropped out of wicketstuff-core. > >> And: YES, I would help to maintain such a stable core of wicketstuff. > Great!! I think with 4 or 5 people it shouldn't be a terrible task. > (of course I could be wrong...) > > Bng - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff versioning
2010/3/19 Major Péter > Hi, > > count me in. I would like to help maintain wicketstuff-core too. ;) > When I came to build wicketstuff-core, sometimes I end up fixing > dependency issues and other stuff in others projects, but I don't commit > them, because I don't want to modify someone else's code without her/his > knowledge, and finding out who is the current maintainer of the project > is not that simple... Am I the only one with this? Or if I catch for > example a maven config bug, should I just fix and commit them to make > the repo right? > I have hit the same problem in the past. Before, I never did like changing someone else's project without their permission. But, then I decided that if I was trying to build a release, and it was just a Maven config or a simple compile issue, I fixed it and committed it - without asking. And if it wasn't simple to fix, I commented out that module (in the wicketstuff-core pom) and then built without that piece. -- Jeremy Thomerson http://www.wickettraining.com
Re: Wicketstuff versioning
Hi, count me in. I would like to help maintain wicketstuff-core too. ;) When I came to build wicketstuff-core, sometimes I end up fixing dependency issues and other stuff in others projects, but I don't commit them, because I don't want to modify someone else's code without her/his knowledge, and finding out who is the current maintainer of the project is not that simple... Am I the only one with this? Or if I catch for example a maven config bug, should I just fix and commit them to make the repo right? Regards, Peter 2010-03-19 15:04 keltezéssel, Boris Goldowsky írta: > nino martinez wael wrote: >> I'll be happy to join in Boris. >> > That would be awesome, thanks Nino. > > I'm thinking the first thing would be to bump the wicket dependency to > v1.4.7 and do a maven release of the current state of wicketstuff-core > as version 1.4.7. Make sense? Is that something you could do? > > Stefan Lindner wrote: >> Perhaps we should define an island of stability (like the name >> wickststuff-core implies). > I agree with that & the rest of your message. Jeremy put together a > nice framework under wicketstuff-core, and there are a decent set of > modules in there. How about calling those the stable set. Anyone can > put something into core - as long as it works and they're willing to > make some effort to keep it working. If one of the core modules breaks > with a future wicket version, and no one steps up to fix it, then it > gets dropped out of wicketstuff-core. > >> And: YES, I would help to maintain such a stable core of wicketstuff. > Great!! I think with 4 or 5 people it shouldn't be a terrible task. > (of course I could be wrong...) > > Bng - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff versioning
nino martinez wael wrote: I'll be happy to join in Boris. That would be awesome, thanks Nino. I'm thinking the first thing would be to bump the wicket dependency to v1.4.7 and do a maven release of the current state of wicketstuff-core as version 1.4.7. Make sense? Is that something you could do? Stefan Lindner wrote: Perhaps we should define an island of stability (like the name wickststuff-core implies). I agree with that & the rest of your message. Jeremy put together a nice framework under wicketstuff-core, and there are a decent set of modules in there. How about calling those the stable set. Anyone can put something into core - as long as it works and they're willing to make some effort to keep it working. If one of the core modules breaks with a future wicket version, and no one steps up to fix it, then it gets dropped out of wicketstuff-core. And: YES, I would help to maintain such a stable core of wicketstuff. Great!! I think with 4 or 5 people it shouldn't be a terrible task. (of course I could be wrong...) Bng - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicketstuff versioning
Perhaps we should define an island of stability (like the name wickststuff-core implies). Maybe under another name (e.g. wicketstuff-stable). This place should only hold projects that are maintained and that are buildable with actual wicket versions. The rest of wicketstuff should be left as ist is: free for everyone and sometimes out of date. Even if a project is not supported anymore t might be helpful to get some inspiration for my own work. And: YES, I would help to maintain such a stable core of wicketstuff. Stefan -Ursprüngliche Nachricht- Von: Martin Grigorov [mailto:mcgreg...@e-card.bg] Gesendet: Donnerstag, 18. März 2010 09:09 An: users@wicket.apache.org Betreff: Re: Wicketstuff versioning Here is how I understand wicketstuff hosting: Someone makes something cool and decides to share it with the community. Then this person asks in the mailing lists for commit permissions. After that this person jumps into something else and don't have time to support the project. Later on I need this cool feature and the first place to look for it is wicketstuff.org (you know because of the advertising in the mailing lists). Then I add or improve something to this project and again share it with the community. After me someone else does the same and the project lives. Otherwise some volunteer (like Jeremy) decides that this project is not maintained and moves it to attic. About GoogleCode, github, bitbucket, ... yes, you can put your project there. But there are two problems: 1) it is less visible it is not next to the other wicketstuff projects where everyone checks first 2) when you don't have time to support it you need to give commit permissions to the people who have time or they will start clone it all over Internet. And this will just confuse further future users/maintainers On Wed, 2010-03-17 at 15:25 -0400, Boris Goldowsky wrote: > It sounds like whoever is responsible for wicketstuff needs to make a > clear choice here. > > Is Wicketstuff going to be maintained as a place where lots of useful > add-ons will live? If so, it needs someone to take a slightly more > active role as curator; make sure the releases are done in parallel with > wicket releases, make sure modules don't get dumped there without at > least some documentation; and weed out modules that are abandoned, where > no one volunteers to take on maintenance, or whose function has been > absorbed into wicket's core. > > Alternatively, make it clear that wicketstuff is NOT going to be > maintained, and people like me who would like to share modules will > share them in some other way - on Google code, a personal website, or > whatever. > > Either way is ok I think, it just would be useful for those of us who > are interested in contributing modules to know. > > Thanks > Bng > > > Jeremy Thomerson wrote: > > Really, it should match what's at trunk of Wicket, which should be > > 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT. > > But, nobody is really maintaining it any more, so it's a free-for-all. > > That's always been the problem with WicketStuff. > > > > -- > > Jeremy Thomerson > > http://www.wickettraining.com > > > > > > > > On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky wrote: > > > > > >> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of SVN. > >> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket? > >> > >> Bng > >> > >> > >> - > >> 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
Re: Wicketstuff versioning
I'll be happy to join in Boris. 2010/3/18 Boris Goldowsky > Thank you for your thoughts Jeremy -- and your previous work on > WicketStuff. I am certainly unhappy to hear that it felt like torture > and that junk was being dumped on you rather than getting support from > the community. > > I'd volunteer to put a bit of time into this, but I don't have time to > be sole maintainer either. Maybe there could be a small group who all > helped out - anyone else on this list willing to step up? > > I already offered to fix and update the TinyMCE module, but that is > currently stalled since the necessary dependency is not in the > repository and I don't have permissions to add it. > > Bng > > > On Wed, 2010-03-17 at 16:21 -0500, Jeremy Thomerson wrote: > > > > > I tried. I don't have the time it takes. With the free-for-all access > that > > is given to it, people consistently commit inconsistent junk that they > don't > > ever intend on maintaining in there. Feel free to take over - most of > the > > reorganization work is already done for you - by me. You can pick up > where > > I left off and carry the torture stake as far as you want. > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Wicketstuff versioning
Thank you for your thoughts Jeremy -- and your previous work on WicketStuff. I am certainly unhappy to hear that it felt like torture and that junk was being dumped on you rather than getting support from the community. I'd volunteer to put a bit of time into this, but I don't have time to be sole maintainer either. Maybe there could be a small group who all helped out - anyone else on this list willing to step up? I already offered to fix and update the TinyMCE module, but that is currently stalled since the necessary dependency is not in the repository and I don't have permissions to add it. Bng On Wed, 2010-03-17 at 16:21 -0500, Jeremy Thomerson wrote: > > I tried. I don't have the time it takes. With the free-for-all access that > is given to it, people consistently commit inconsistent junk that they don't > ever intend on maintaining in there. Feel free to take over - most of the > reorganization work is already done for you - by me. You can pick up where > I left off and carry the torture stake as far as you want. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff versioning
Exactly (I wrote something similar, but it apparently was declared spam:(). We could of course improve our structure as always, lifting the level a bit. As I see it wicketstuff are as ops4j, which brings advantages and disadvantages as well. -regards Nino 2010/3/18 Martin Grigorov > Here is how I understand wicketstuff hosting: > > Someone makes something cool and decides to share it with the community. > Then this person asks in the mailing lists for commit permissions. After > that this person jumps into something else and don't have time to > support the project. Later on I need this cool feature and the first > place to look for it is wicketstuff.org (you know because of the > advertising in the mailing lists). Then I add or improve something to > this project and again share it with the community. After me someone > else does the same and the project lives. Otherwise some volunteer (like > Jeremy) decides that this project is not maintained and moves it to > attic. > > About GoogleCode, github, bitbucket, ... yes, you can put your project > there. But there are two problems: > 1) it is less visible > it is not next to the other wicketstuff projects where everyone checks > first > 2) when you don't have time to support it you need to give commit > permissions to the people who have time or they will start clone it all > over Internet. And this will just confuse further future > users/maintainers > > On Wed, 2010-03-17 at 15:25 -0400, Boris Goldowsky wrote: > > It sounds like whoever is responsible for wicketstuff needs to make a > > clear choice here. > > > > Is Wicketstuff going to be maintained as a place where lots of useful > > add-ons will live? If so, it needs someone to take a slightly more > > active role as curator; make sure the releases are done in parallel with > > wicket releases, make sure modules don't get dumped there without at > > least some documentation; and weed out modules that are abandoned, where > > no one volunteers to take on maintenance, or whose function has been > > absorbed into wicket's core. > > > > Alternatively, make it clear that wicketstuff is NOT going to be > > maintained, and people like me who would like to share modules will > > share them in some other way - on Google code, a personal website, or > > whatever. > > > > Either way is ok I think, it just would be useful for those of us who > > are interested in contributing modules to know. > > > > Thanks > > Bng > > > > > > Jeremy Thomerson wrote: > > > Really, it should match what's at trunk of Wicket, which should be > > > 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT. > > > But, nobody is really maintaining it any more, so it's a free-for-all. > > > That's always been the problem with WicketStuff. > > > > > > -- > > > Jeremy Thomerson > > > http://www.wickettraining.com > > > > > > > > > > > > On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky >wrote: > > > > > > > > >> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of > SVN. > > >> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket? > > >> > > >> Bng > > >> > > >> > > >> - > > >> 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 > >
Re: Wicketstuff versioning
Here is how I understand wicketstuff hosting: Someone makes something cool and decides to share it with the community. Then this person asks in the mailing lists for commit permissions. After that this person jumps into something else and don't have time to support the project. Later on I need this cool feature and the first place to look for it is wicketstuff.org (you know because of the advertising in the mailing lists). Then I add or improve something to this project and again share it with the community. After me someone else does the same and the project lives. Otherwise some volunteer (like Jeremy) decides that this project is not maintained and moves it to attic. About GoogleCode, github, bitbucket, ... yes, you can put your project there. But there are two problems: 1) it is less visible it is not next to the other wicketstuff projects where everyone checks first 2) when you don't have time to support it you need to give commit permissions to the people who have time or they will start clone it all over Internet. And this will just confuse further future users/maintainers On Wed, 2010-03-17 at 15:25 -0400, Boris Goldowsky wrote: > It sounds like whoever is responsible for wicketstuff needs to make a > clear choice here. > > Is Wicketstuff going to be maintained as a place where lots of useful > add-ons will live? If so, it needs someone to take a slightly more > active role as curator; make sure the releases are done in parallel with > wicket releases, make sure modules don't get dumped there without at > least some documentation; and weed out modules that are abandoned, where > no one volunteers to take on maintenance, or whose function has been > absorbed into wicket's core. > > Alternatively, make it clear that wicketstuff is NOT going to be > maintained, and people like me who would like to share modules will > share them in some other way - on Google code, a personal website, or > whatever. > > Either way is ok I think, it just would be useful for those of us who > are interested in contributing modules to know. > > Thanks > Bng > > > Jeremy Thomerson wrote: > > Really, it should match what's at trunk of Wicket, which should be > > 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT. > > But, nobody is really maintaining it any more, so it's a free-for-all. > > That's always been the problem with WicketStuff. > > > > -- > > Jeremy Thomerson > > http://www.wickettraining.com > > > > > > > > On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky wrote: > > > > > >> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of SVN. > >> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket? > >> > >> Bng > >> > >> > >> - > >> 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
Re: Wicketstuff versioning
See other reply to Boris. Anyone can pick it up and become the maintainer of WS. But it's going to take a group of people who set some rules about it and then follow them. The problem with that is that then people *will* whine because they always wanted WicketStuff to be a no-rules repo. I would like to see the wicketstuff-core things that I reorganized last year (and the year before) to continue to make progress and be released consistently. But I don't have the time, and when I asked for help, although there were offers, no one ever stepped up to the plate. So, if the community doesn't care that much, why should I? I'd rather put my time into things that I can actually control and make a positive effect with. -- Jeremy Thomerson http://www.wickettraining.com 2010/3/17 Major Péter > I always thought, that Jeremy was the maintainer of WicketStuff. Guess I > was wrong. :) > Sidenote: > Also, I really wanted to write docs for the javaee-inject project, but I > don't have confluence access, and the signup gives: > org.springframework.transaction.UnexpectedRollbackException: Transaction > rolled back because it has been marked as rollback-only > > I guess this isn't working since the overspammed confluence event. I > already wrote two e-mails to the dev list, but still no answer, so I'm > confused too about the wicketstuff's future... > > Regards, > Peter > > 2010-03-17 20:25 keltezéssel, Boris Goldowsky írta: > > It sounds like whoever is responsible for wicketstuff needs to make a > > clear choice here. > > > > Is Wicketstuff going to be maintained as a place where lots of useful > > add-ons will live? If so, it needs someone to take a slightly more > > active role as curator; make sure the releases are done in parallel with > > wicket releases, make sure modules don't get dumped there without at > > least some documentation; and weed out modules that are abandoned, where > > no one volunteers to take on maintenance, or whose function has been > > absorbed into wicket's core. > > > > Alternatively, make it clear that wicketstuff is NOT going to be > > maintained, and people like me who would like to share modules will > > share them in some other way - on Google code, a personal website, or > > whatever. > > > > Either way is ok I think, it just would be useful for those of us who > > are interested in contributing modules to know. > > > > Thanks > > Bng > > > > > > Jeremy Thomerson wrote: > >> Really, it should match what's at trunk of Wicket, which should be > >> 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT. > >> But, nobody is really maintaining it any more, so it's a free-for-all. > >> That's always been the problem with WicketStuff. > >> > >> -- > >> Jeremy Thomerson > >> http://www.wickettraining.com > >> > >> > >> > >> On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky > >> wrote: > >> > >> > >>> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of > SVN. > >>> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket? > >>> > >>> Bng > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Wicketstuff versioning
Comments inline -- Jeremy Thomerson http://www.wickettraining.com On Wed, Mar 17, 2010 at 2:25 PM, Boris Goldowsky wrote: > It sounds like whoever is responsible for wicketstuff needs to make a clear > choice here. > The community is responsible for WicketStuff. This includes you. > Is Wicketstuff going to be maintained as a place where lots of useful > add-ons will live? If so, it needs someone to take a slightly more active > role as curator; make sure the releases are done in parallel with wicket > releases, make sure modules don't get dumped there without at least some > documentation; and weed out modules that are abandoned, where no one > volunteers to take on maintenance, or whose function has been absorbed into > wicket's core. > I tried. I don't have the time it takes. With the free-for-all access that is given to it, people consistently commit inconsistent junk that they don't ever intend on maintaining in there. Feel free to take over - most of the reorganization work is already done for you - by me. You can pick up where I left off and carry the torture stake as far as you want. Alternatively, make it clear that wicketstuff is NOT going to be maintained, > and people like me who would like to share modules will share them in some > other way - on Google code, a personal website, or whatever. > *Pieces* of WicketStuff will not be maintained. Unfortunately, that's the way it's always been, and if you intend on releasing something that really is going to be maintained, I'd definitely suggest using something else like Google Code, GitHub, etc... > Either way is ok I think, it just would be useful for those of us who are > interested in contributing modules to know. > Search the list - you'll see many similar thoughts to this over the years related to WicketStuff. Thanks > Bng > > > > Jeremy Thomerson wrote: > >> Really, it should match what's at trunk of Wicket, which should be >> 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT. >> But, nobody is really maintaining it any more, so it's a free-for-all. >> That's always been the problem with WicketStuff. >> >> -- >> Jeremy Thomerson >> http://www.wickettraining.com >> >> >> >> On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky > >wrote: >> >> >> >>> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of SVN. >>> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket? >>> >>> Bng >>> >>> >>> - >>> 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 > >
Re: Wicketstuff versioning
I always thought, that Jeremy was the maintainer of WicketStuff. Guess I was wrong. :) Sidenote: Also, I really wanted to write docs for the javaee-inject project, but I don't have confluence access, and the signup gives: org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only I guess this isn't working since the overspammed confluence event. I already wrote two e-mails to the dev list, but still no answer, so I'm confused too about the wicketstuff's future... Regards, Peter 2010-03-17 20:25 keltezéssel, Boris Goldowsky írta: > It sounds like whoever is responsible for wicketstuff needs to make a > clear choice here. > > Is Wicketstuff going to be maintained as a place where lots of useful > add-ons will live? If so, it needs someone to take a slightly more > active role as curator; make sure the releases are done in parallel with > wicket releases, make sure modules don't get dumped there without at > least some documentation; and weed out modules that are abandoned, where > no one volunteers to take on maintenance, or whose function has been > absorbed into wicket's core. > > Alternatively, make it clear that wicketstuff is NOT going to be > maintained, and people like me who would like to share modules will > share them in some other way - on Google code, a personal website, or > whatever. > > Either way is ok I think, it just would be useful for those of us who > are interested in contributing modules to know. > > Thanks > Bng > > > Jeremy Thomerson wrote: >> Really, it should match what's at trunk of Wicket, which should be >> 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT. >> But, nobody is really maintaining it any more, so it's a free-for-all. >> That's always been the problem with WicketStuff. >> >> -- >> Jeremy Thomerson >> http://www.wickettraining.com >> >> >> >> On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky >> wrote: >> >> >>> The wicketstuff-core is calling itself version 1.4.2 in the HEAD of SVN. >>> Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket? >>> >>> Bng - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff versioning
It sounds like whoever is responsible for wicketstuff needs to make a clear choice here. Is Wicketstuff going to be maintained as a place where lots of useful add-ons will live? If so, it needs someone to take a slightly more active role as curator; make sure the releases are done in parallel with wicket releases, make sure modules don't get dumped there without at least some documentation; and weed out modules that are abandoned, where no one volunteers to take on maintenance, or whose function has been absorbed into wicket's core. Alternatively, make it clear that wicketstuff is NOT going to be maintained, and people like me who would like to share modules will share them in some other way - on Google code, a personal website, or whatever. Either way is ok I think, it just would be useful for those of us who are interested in contributing modules to know. Thanks Bng Jeremy Thomerson wrote: Really, it should match what's at trunk of Wicket, which should be 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT. But, nobody is really maintaining it any more, so it's a free-for-all. That's always been the problem with WicketStuff. -- Jeremy Thomerson http://www.wickettraining.com On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky wrote: The wicketstuff-core is calling itself version 1.4.2 in the HEAD of SVN. Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket? Bng - 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
Re: Wicketstuff versioning
Really, it should match what's at trunk of Wicket, which should be 1.5-SNAPSHOT. There should be a branch for 1.4.x that is 1.4-SNAPSHOT. But, nobody is really maintaining it any more, so it's a free-for-all. That's always been the problem with WicketStuff. -- Jeremy Thomerson http://www.wickettraining.com On Tue, Mar 16, 2010 at 1:00 PM, Boris Goldowsky wrote: > The wicketstuff-core is calling itself version 1.4.2 in the HEAD of SVN. > Shouldn't this be updated to 1.4.7 now to keep in sync with Wicket? > > Bng > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
