PyPDF4
PyPDF4 copied to clipboard
claird
Adhere to Semantic Versioning
Probably the current versioning style is already close to it, but I propose to stick more seriously to the succinct specification of Semantic Versioning (semver) 2.0.0. This will aid communicating the progress of the project to the external users of PyPDF.
A first problem that ensues is: where should PyPDF4' versioning begin? Since it is named somehow differently from its predecessor PyPDF2, shall it be treated as a new project and start at 0.1.0? Or begin outright from 4.0.0?
An advantage of 0.1.0 is that it communicates its non-public state, which PyPDF4 might be in. 4.0.0 has not that interpetation. On the other hand, PyPDFx has already been subject to long use and be considered in production, which 4.0.0 can adequately target.
4.0.0 would make sense if PyPDF2 was 2.x.y which is not the case (the last version is 1.26.0). Given that I would stick with 0.1.0.
Additionally, there's the weirdness that no one knows what happens with PyPDF3.
Indeed, I believe that the previous versions of PyPDF4 so far have been misversioned, and that I have good reasons to impose a proper versioning scheme. 1.x.y makes no sense for PyPDF2 - should have been 2.x.y AFAIK.
No one should be concerned about PyPDF3.
I personally agree with @xilopaint that 0.1.0 is best here. I see it very well as fork of the prod-ready pypdf2 but also as a restart, new project, many changes going probably not stable etc... you get my point. 0.1.0 and sticking to a proper versioning scheme is thus best IMHO
I'm not telling that anyone should be concerned about PyPDF3, I just told that adopting a 4.x.y format is weird while PyPDF2 is 1.x.y and no one knows what happens with PyPDF3.
I personally dislike the fact this project couldn't be named PyPDF3 but the reasons behind this are not my business.
The restart to 0.1.0 is fine for me too. Let's hear what @claird et al. have to say :wink:.
What I have to say in regard to 0.1.0 is ... oops: https://pypi.org/project/PyPDF4/1.27.0/ Is there any realistic way we can move from 1.27.0 to 0.1.0?
Cameron Laird, vice president We make computers work for people.
On Tue, Sep 11, 2018 at 10:43 AM, Oscar [email protected] wrote:
The restart to 0.1.0 is fine for me too. Let's hear what @claird https://github.com/claird et al. have to say 😉.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/claird/PyPDF4/issues/16#issuecomment-420320152, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbN9J3Gf6i8A348w8lcOT26RWuMpAVfks5uZ9oFgaJpZM4WjfHT .
What I have to say in regard to 0.1.0 is ... oops: https://pypi.org/project/PyPDF4/1.27.0/ Is there any realistic way we can move from 1.27.0 to 0.1.0?
Hmm it is possible to delete an already published package on pypi. Though I don't know if they allow you to publish a package with a lower version number than the one you deleted. May try that and try publishing a 0.0.1 ?
May try that and try publishing a 0.0.1 ?
If you do, please start at 0.1.0. Patch versioning only when introducing bug fixes and possibly other assimilated cases.
@newnone I suggested 0.0.1 just for testing... if it works, delete it again and publish the first version as 0.1.0 ... :-)
Let's break this by cases:
- If it works with
0.1.0we are done and no further updating is needed - If it doesn't, we "remove" (but were we able to upload the package to PyPI in the first place, if "it didn't work"?) the package from PyPI and with that the
0.1.0release.
Can this work? :-P (I appreciate the suggestion, anyway.)
Don't jump backwards to 0.1.0. This code builds on the contributions of 70 people already. It's not a reboot of the codebase.
Calling it 1.27.0 was the right decision when demonstrating PyPI uploads. Following semantic versioning will be a good decision. Jumping backwards in version numbers will lead to confusion about the stability of a codebase that has not been completely rewritten from scratch.
Move forward.
Don't jump backwards to 0.1.0. This code builds on the contributions of 70 people already. It's not a reboot of the codebase.
I agree, and I've done so in a past comment of "Package name is confusing" a few months ago, after consideration.
Amongst other things, the proposal also involves collpasing the number suffix 4 from the package name on PyPI, GitHub etc. One single PyPDF, with versions identified by the very version number.