I think we could begin by working out some constraints for the feature... First, I think it should be possible to deprecate (or undeprecate) an artifact without compiling a new version of it.
This is because: - In some legacy code situations (e.g. when the code was not checked in to VCS), nobody can compile the artifact any more. We would not want this to prevent us deprecating the artifact. - Deprecation and undeprecation should be quick operations. Compiling and releasing new versions can take significant time. This constraint suggests that a deprecation indicator should be something applied *to* an artifact rather than part *of* an artifact. It would lead us towards putting the indicator in the repository metadata, not the POM. A comparison with other systems: - NPM puts deprecation indicators in repository metadata. - Nuget puts deprecation indicators in repository metadata. - Cocoapods puts its `deprecated` property in the Podspec (the equivalent of the POM). This means you have to compile a new version of a pod just to un/deprecate it. I believe it also means that Cocoapods clients must scan forward from a Podspec's current dependency versions to find the closest future versions that have a `deprecated` marker. I think is the wrong approach for the reasons explained above. Chris --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
