What do we currently do for plugins? What do we currently do for core? Is there in difference in the approach taken?
We call for a vot for vX.Y.Z of <arbitrary plugin> (plugins's [recently at least] do not appear to go throught he beta/RC phases). Can someone please spell out a sequence of events (by time) as to what happens through the entire process? From prep to vote to ending up in central. And the same sequnce, but for a failed vote, and it's revoting (we've used the same version no again, here, have we not?) -Chris On Thu, May 30, 2013 at 6:11 AM, Fred Cooke <fred.co...@gmail.com> wrote: > > > > -1 for actual releases: it would create more mess imo for end users if > > there's many bizarre jumps in numbering > > > The thing with this argument is that it's very, very weak. If a missed > version confuses a user, they're basically brain-dead. Assuming your users > are brain dead is _always_ dangerous. Assuming the users or a _development_ > tool are brain-dead is that in and of itself IMO. > > A random example from central that I gave to Robert earlier: > > > http://search.maven.org/#search|gav|1|g%3A%22antlr%22%20AND%20a%3A%22antlr%22 > > I don't know about the rest of you... but I'm not confused by the absence > of 2.7.3 in any way shape or form. I'm additionally not confused by the > absence of 2.7.8, 2.7.9, 2.7.10, etc, nor 2.8.* nor 2.9.* It's meaningless > to me that they're absent. I use and test a version (usually latest) and > verify it functions adequately for my needs, then I depend on it (dep or > plugin equally) and that's it. If I find a flaw, or need to use a new > feature, then I can go looking for the best version that is compatible with > my setup, that contains it (again, likely latest, API change not > withstanding). > > Being worried about developers being confused by a non-sequential set of > binaries to choose from is bizarre at best. Developers, even the bad ones, > are generally a fairly intelligent bunch. > > This is not winamp! :-p (nor VLC) > > Fred. >
