| Xqt added a comment. |
In T106121#3858860, @Dalba wrote:In T106121#3858703, @Lokal_Profil wrote:The problem with that is that versioning is today done separately from doing a deprecating commit and to the one doing the commit the current version isn't necessarily clear.
I suppose we could use after=<latest_version> as the deprecation parameter. However, the idea was mainly for semantic versioning. For date versioning, it might not matter.
latest_version is completly unclear or in other words it is undefined. A lot of deprecation warnings are done when creating the rewrite branch from previous compat branch. We could say that compat is the 1.0 branch [1] whereas 2.0 was a separate branch based on rewrite development where some patches where ported to from time to time. After we dropped that 2.0 branch we started the 3.0 counting [2].
Finding out the deprecation history, the timestamp is the only usefull value we could extract from repository.
I believe the current scheme is date versioning only but with a 3.0 prefix to distinguish it from the 2.0 efforts. We could possibly change to 3.DATE to clarify that but I'm not sure this it's needed.
I think we should indicate the major 3 release Independent of the timestamp versioning.
I guess the main question that remains is how we are going to handle backward incompatible changes in this versioning scheme.
If we are going to bump the main version for any backward incompatible change, then maybe having since=<major_version> would be enough. On the other hand, if deprecated code removal is going to be date-based only, e.g. after 1 year of deprecation as some have suggested, then a timestamp looks more appropriate.
I propose to increase the minor release for backward incompatibility e.g. remove older depecated parts. They get a tag which is the version number [3] and could easily restored from repository (but without any backports).
But I have no preferences about the mayor release number; maybe this could indicate a new python code base or revoking some (like py 2.6 for example)
[1] https://pypi.org/project/PyWikipediaBot/#history
[2] https://pypi.org/project/pywikibot/#history
[3] https://gerrit.wikimedia.org/r/#/admin/projects/pywikibot/core,tags
Cc: gerritbot, zhuyifei1999, JeanFred, MZMcBride, Ladsgroup, Magul, TerraCodes, Legoktm, Luke081515, hashar, Jay8g, Dalba, Lokal_Profil, StudiesWorld, Multichill, valhallasw, jayvdb, XZise, Ricordisamoa, Aklapper, Xqt, pywikibot-bugs-list, Adrian1985, Cpaulf30, Baloch007, Darkminds3113, Lordiis, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, Tbscho, rafidaslam, MayS, Lewizho99, Mdupont, JJMC89, Maathavan, TomT0m, Avicennasis, Wong128hk, fbstj, Masti, Alchimista, Rxy
_______________________________________________ pywikibot-bugs mailing list pywikibot-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikibot-bugs
