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
