I need to remind people about the Apache rules here. Yes you can have weekly builds. No you can't 'advertise them' in any way that is likely to attract the attention of mere users as opposed to people engaged in the development community. Please don't shoot me, I'm just the messenger here.
On Wed, Feb 19, 2014 at 11:25 AM, Jason van Zyl <ja...@takari.io> wrote: > Agreed, if they small enhancements then I don't really want to release 4 > things issues in a patch release and then another 5. Generally I'm fine with > small enhancements, or small fixes going into patch releases, along with > anything marked @provisional as I'd rather have the experimental code in a > release then rotting in a branch. > > That said I'm not averse to calling the next release 3.3.0. A 3.2.2 isn't > strictly semver and I certainly would like to have this for 4.0.0 but right > now I don't have a strong opinion. If we want to decide to use semver (which > we never have) and want to try now that's fine. We need to get there at some > point. > > But I'm still off the mind the best approach is what Igor outlined. No > official weekly releases, we just make the infrastructure work to publish > weekly integration builds and let people consume them as required, and any > changes in those get rolled up into official release schedule. > > On Feb 19, 2014, at 6:36 AM, Paul Benedict <pbened...@apache.org> wrote: > >> I don't see any necessity to restrict patch releases to patches only -- as >> long as any new functionality is a tiny enhancement and doesn't make >> incompatibilities. Save medium/major structural changes for a new minor >> version. >> >> >> On Wed, Feb 19, 2014 at 7:37 AM, Benson Margulies >> <bimargul...@gmail.com>wrote: >> >>> A bit of a recap: >>> >>> Let's say that our goal as a group was to be very responsive to user's >>> bug reports. >>> >>> So, we'd want to make fixes and releases, 'promptly', for some >>> definition of prompt. >>> >>> But no one will install those releases if they are not confident that >>> they are, in fact, not going to have unexpected consequences. >>> >>> From a black-box standpoint, this can only be achieved with really >>> strong integration tests. >>> >>> From a white-box standpoint, it seems to me that the Maven core has a >>> tendency towards complex interactions in which a fix to problem (a) >>> can have unexpected consequence (b). >>> >>> So, either way, Jason's views about testing seem spot-on. This leaves >>> a question: should we be trying, still, to follow up a 3.2.0 with a >>> pure bugfix 3.2.1, and holding off on structural repairs or new >>> features until 3.3? One view is that we should try to get some of the >>> tests improved and some of the structural repairs done before we make >>> any attempt at semver/responsive releases. The other view is that >>> should try to deliver on semver as best we can. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> >> -- >> Cheers, >> Paul > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > First, the taking in of scattered particulars under one Idea, > so that everyone understands what is being talked about ... Second, > the separation of the Idea into parts, by dividing it at the joints, > as nature directs, not breaking any limb in half as a bad carver might. > > -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
