search

claird / PyPDF4

A utility to read and write PDFs with Python
obsolete-https://pythonhosted.org/PyPDF2/
Other
330 stars 61 forks source link

Adhere to Semantic Versioning #16

Open acsor opened 6 years ago

acsor commented 6 years ago

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.

xilopaint commented 6 years ago

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.

acsor commented 6 years ago

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.

sim0nx commented 6 years ago

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

xilopaint commented 6 years ago

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.

acsor commented 6 years ago

The restart to 0.1.0 is fine for me too. Let's hear what @claird et al. have to say :wink:.

claird commented 6 years ago

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 notifications@github.com 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 .

sim0nx commented 6 years ago

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 ?

acsor commented 6 years ago

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.

sim0nx commented 6 years ago

@newnone I suggested 0.0.1 just for testing... if it works, delete it again and publish the first version as 0.1.0 ... :-)

acsor commented 6 years ago

Let's break this by cases:

Can this work? :-P (I appreciate the suggestion, anyway.)

kurtmckee commented 5 years ago

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.

acsor commented 5 years ago

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.