from a couple of replies to this thread i am a little confused. are we talking about keeping experimental things in different modules on master or different branches?
obviously the big problem is that not everyone has access to the apache git repo, so projects will still pop up on github, etc, if they require collaboration from non-committers. if, this is directed at committers, there are a couple of issues that need to be discussed. 1) sometimes its not possible to release the code, ie wicket-cdi which lacks necessary maven dependencies in central. what do we do in those cases? 2) sometimes a project is just an idea to play with. once we release it as a 0.1 module we have to at least somewhat maintain it. and what if the idea doesnt pan out, is it ok to just drop the module? what happens with the dropped code if someone outside wicket wants to work on it, does it move back to github? -igor On Mon, Apr 2, 2012 at 5:49 AM, Martijn Dashorst <martijn.dasho...@gmail.com> wrote: > The trend seems to be to do experimental things at wicketstuff or > personal github accounts with the intention of bringing that back to > Wicket at a later time. IMO this is the wrong way. The Apache Way > should be (IMO): also do experimental stuff at Apache, within the > purview of the PMC. > > When things are not mature enough for a 1.0 release, we can either > mark it @Experimental or @Beta, or deliver the code in a side project > with a version number of < 1.0 until the code is mature enough to be > included in Wicket proper. In the mean time, the experimental projects > will be released with the wicket proper releases, but with a release > version < 1.0, marking them as unfinished. > > So for example, a Wicket Push/Comet/Atmosphere project would reside in: > > wicket/ > core/ > extensions/ > .../ > push/ > > With a pom that specifies the version as 0.1-SNAPSHOT. When released > it will released as 0.1, and the next version will become > 0.2-SNAPSHOT. Iterate ad nauseam, and when the code base is mature > enough, reversion to be on par with the proper Wicket release version > (e.g. 6.1). > > The benefits of this are: > - no need to go project hopping, there is one central place where we > can find Wicket code, proper and experimental > - better visibility of the project within Wicket and the wicket community > - easier to attract new core developers to Wicket > - no need for software grants and 'white washing' of code through the > http://incubator.apache.org/ip-clearance/index.html > - clearly defined trajectory for code bases developed by Wicket > committers to go into core > - no need to explain to the board why we have zero commits at > apache's git and everything happening outside the purview of the PMC > at external servers > > Martijn
