On 3 March 2013 22:41, Benson Margulies <bimargul...@gmail.com> wrote:
> As I see it, you are using the version number to communicate with the > tiny number of people who have made plugins that depend on Aether. > > I would rather see us use the version number to communicate with the > vast number of people who use Maven. > > So, I'd switch to Eclipse Aether, including the need to fork a few > plugins, as 3.2, and use the number 4.0.0 for a version that has real > user-visible impact and value. > Well I agree with Semantic Versioning, so the question here that dictates 3.2 vs 4.0 is whether we see Sonatype Aether as part of the exposed supported API of Maven. IIRC the stated position is that plugin authors are not supposed to rely on the Sonatype Aether API. If plugin authors have relied on it then they are responsible for ensuring that the plugin works in its absence... that would strongly indicate that 3.2 (or 3.1 if at the same time as SLF4J) is the correct SemVer version... but if you view the Sonatype Aether API as being part of the exposed supported API of Maven (as opposed to leaked unsupported API) then 4.0 would be the correct SemVer -Stepjen > > If you presented a long list of wonderful user-visible improvements > that would result from the adoption of the new Aether, I'd be happier > with your proposal. > > > On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl <ja...@tesla.io> wrote: > > > > On Mar 3, 2013, at 2:23 PM, Mark Derricutt <m...@talios.com> wrote: > > > >> A quick answer whilst I let my thoughts dwell on the full long post.. > >> > >> If we're jumping to a major release here, is this a viable time to also > update the schema and address of the things we've long been wanting there? > ( mixins of some form ) - or is this out of scope ( of this discussion at > least ). > >> > > > > To me it's out of scope. I want to get the API changes out there and > signal the potential of major API breakages. Features can be rolled out > whenever. To me the change in versions is to signal API breakage, not > feature addition. > > > >> Mark > >> > >> > >> Jason van Zyl wrote: > >>> > >>> Hi, > >>> > >>> No one seems to object to doing a release with the SLF4J support > without the isolation so I wanted to discuss what happens when we integrate > Eclipse Aether and suggest an alternate release path. > >> > > > > Thanks, > > > > Jason > > > > ---------------------------------------------------------- > > Jason van Zyl > > Founder & CTO, Sonatype > > Founder, Apache Maven > > http://twitter.com/jvanzyl > > --------------------------------------------------------- > > > > the course of true love never did run smooth ... > > > > -- Shakespeare > > > > > > > > > > > > > On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl <ja...@tesla.io> wrote: > > > > On Mar 3, 2013, at 2:23 PM, Mark Derricutt <m...@talios.com> wrote: > > > >> A quick answer whilst I let my thoughts dwell on the full long post.. > >> > >> If we're jumping to a major release here, is this a viable time to also > update the schema and address of the things we've long been wanting there? > ( mixins of some form ) - or is this out of scope ( of this discussion at > least ). > >> > > > > To me it's out of scope. I want to get the API changes out there and > signal the potential of major API breakages. Features can be rolled out > whenever. To me the change in versions is to signal API breakage, not > feature addition. > > > >> Mark > >> > >> > >> Jason van Zyl wrote: > >>> > >>> Hi, > >>> > >>> No one seems to object to doing a release with the SLF4J support > without the isolation so I wanted to discuss what happens when we integrate > Eclipse Aether and suggest an alternate release path. > >> > > > > Thanks, > > > > Jason > > > > ---------------------------------------------------------- > > Jason van Zyl > > Founder & CTO, Sonatype > > Founder, Apache Maven > > http://twitter.com/jvanzyl > > --------------------------------------------------------- > > > > the course of true love never did run smooth ... > > > > -- Shakespeare > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
