Hi, Given that I've been gone for some time from this list things might have changed. If that's the case I'm sure someone will correct me :)
But it used to be the way to do things when you have a chain of related components, which is quite common in Maven. If we take maven-resouces-plugin, which I'm working on right now, it has a dependency on maven-filtering which contains all the code for filtering resources. That in turn depends on maven-shared-util, which is specified as a SNAPSHOT in maven-filtering. When the time comes to make a release, all these SNAPSHOT dependencies will need to be addressed. So you have a "release train" where you will start with the component furthest down the dependency tree, release that and then continue on with the next one until you reach the top. In my example the order will be maven-shared-util, maven-filtering and finally maven-resources-plugin. Dennis Lundberg Den tors 16 juli 2020 kl 17:04 skrev Elliotte Rusty Harold < [email protected]>: > I happened to notice today that the maven-resources-plugin at HEAD in > the repo (not the released version) depends on the latest SNAPSHOT of > maven-filtering: > > https://github.com/apache/maven-resources-plugin/blob/master/pom.xml > > Is this generally OK? That is can we commit code to a repo that > depends on an unreleased SNAPSHOT version of another plugin/library? > If this is considered kosher, it would help unblock some work on the > maven-dependency-plugin. > > > -- > Elliotte Rusty Harold > [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
