On 11-03-14 12:24, sebb wrote:
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.
Sure, I know about the ASF snapshot repo, and we already use that (too).
My intend for the milestone builds is to provide a more stable (even if
temporarily available) artifact to be used for testers.
I already concurred that this cannot be done through Maven Central, which isn't
a big deal really.
The only extra step testers now need to do is check out the milestone tag
themselves and deploy into their own local repository.
Regards, Ate
p.s. I've just created the first milestone 0 tag and will send out a separate
heads-up to this list shortly.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
