Hi, Changing status / metadata of artifacts will break "Release Stability" of Central Repository Once artifacts was release should never change ... https://central.sonatype.org/faq/can-i-change-a-component/
Another case when we don't have source code of an artifact we can do a new pom with relocation information and release the next version. In this case I am afraid that the maintainer of the artifact doesn't want to take care about its or not exist ... so nobody will not use deprecation possibility for such artifacts ... czw., 29 lip 2021 o 15:15 Chris Kilding <chris+ma...@chriskilding.com> napisał(a): > 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 > > -- Sławomir Jaranowski https://twitter.com/SlawekJaran https://github.com/slawekjaranowski https://linkedin.com/in/slawomirjaranowski
