[
https://issues.apache.org/jira/browse/MNG-7979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-7979:
---------------------------------
Fix Version/s: 4.0.0
> API versioning mechanism
> ------------------------
>
> Key: MNG-7979
> URL: https://issues.apache.org/jira/browse/MNG-7979
> Project: Maven
> Issue Type: New Feature
> Components: API
> Reporter: Guillaume Nodet
> Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-11
>
>
> The way to go would be for maven to provide multiple versions of the api at
> the same time imho (in different classloaders of course).
>
> So when maven 4.1.0 loads a plugin, if that plugin has been compiled with api
> in version A (and if the api version B is incompatible, of course, else,
> there's no point...), it will load the plugin with the api A. if the plugin
> has been compiled with api version B, it will use the version B api to load
> the plugin, etc... What exactly A and B are is irrelevant, only Maven has to
> know if they are compatible or not, and thus provide the correct one. If we
> add stuff, the API is still compatible, so we can keep only the latest
> version. The first time we make an incompatible change, we need to provide
> the two APIs in the new maven version. This would allow an easy display of
> warning when loading "old" plugins and ask to update them.
>
> We don't even have to use the same number for the API version and for the
> maven release. We could start at 1 and whenever a breaking change occurs,
> upgrade by 1. This would be stored in the plugin.xml and handled
> transparently.
> We can even start with alpha releases and start releasing plugins using alpha
> apis. The only point is that while in alpha, we would only support the
> latest API and not older ones, but at least, maven could safely identify
> plugins which use an older api.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
