On 11 March 2014 09:11, Ate Douma <a...@douma.nu> wrote: > On 11-03-14 01:00, Gary Gregory wrote: >> >> IMO, if you make artifacts available through MC, then it is a "release", >> whatever you label it, alpha, beta, milestone, and so on, which requires a >> VOTE. > > > Right. Although in my book at the ASF we only formally VOTE on source > releases, never on binary artifacts. > > Also note that providing (only) such convenience binaries, without need for > voting, should be allowed, as specified on [1]: > > "During the process of developing software and preparing a release, > various packages are made available to the developer community for testing > purposes. Do not include any links on the project website that might > encourage non-developers to download and use nightly builds, snapshots, > release candidates, or any other similar package." > > However, also critical is the following sentence: > > "If you find that the general public are downloading such test packages, > then remove them." > > So, it seems like it would be OK if I would provide pre-build milestone > artifacts on a server managed through Apache so I can easily again remove > these, while deploying them to Maven Central would make that rather > difficult. > > The whole point of having these on Maven Central is only as a convenience > (being a Maven repository) to testers. > Putting binary artifacts 'standalone' in like my ASF people ~ folder, would > defeat the purpose. > Those developers willing to test drive these milestone builds then just as > easily, even more so, can checkout the tag and do a local maven install. > > Anyway, I'll agree deploying to Maven Central is not an option without > having a formal voted release first.
There is an ASF snapshot repo. By default Continuum uploads there if the build&test succeeeds. And a manual deploy of a snapshot build should also upload the jars to that repo. So you could point developers (only) at the ASF snapshot repo. But remember that the snapshot repo contents can be updated/dropped at any time. Make sure developers are aware that the contents have not been formally released. > I'll update the roadmap plan description accordingly. > > >> >> If you do not make it available through MC, then you can use an SVN >> revision # or a tag for a more developer oriented milestone marker. >> >> Gary >> >> >> >> On Mon, Mar 10, 2014 at 6:52 PM, Ate Douma <a...@douma.nu> wrote: >> >>> Hi, >>> >>> I just published a high-level roadmap plan towards SCXML 2.0 [1] >>> >>> Part of that plan, which consists of working through a set of milestone >>> targets, is also tagging these milestones "as is", see [2]. >>> >>> As I also described there, these milestone tags will "not represent a >>> formal release and they are only intended and targeted to be used by the >>> Commons SCXML developers, not end users." >>> >>> I would however like to have these milestone tags be deployed and made >>> available through Maven Central. >>> >>> My question is: is this OK for the Commons PMC and can I just create and >>> deploy these tags (using maven release) without need to go through formal >>> voting and validation? >>> >>> Again: these do not represent formal releases, nor will I provide >>> download >>> links or send out announcements, other than a developers heads-up here on >>> dev@. >>> >>> Thanks, Ate >>> >>> p.s. Any feedback on the roadmap plan itself of course also is welcome :) >>> >>> [1] http://commons.apache.org/proper/commons-scxml/roadmap.html >>> [2] http://commons.apache.org/proper/commons-scxml/roadmap. >>> html#Milestone_tags >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
