tl;dr we follow semver.org and I agree with your reasoning, so I'm convinced 1.0 would be fine. While I'm not in favor of the change, I'm ready to disagree and commit.
In the interests of sharing perspectives, here's mine. The issue with semver.org is that it's exclusively focused on change management, and it ignores what I perceive as a cultural association with > 1.0 software to mean "broadly tested and low risk". Is pulp_file at a point where backwards compatibility is a primary concern and prohibited yes. Do the developers of pulp_file recommend it to be run in production, yes. As a user, is it a low risk software due to many folks having already deployed it in production, no. In fact pulp_file is maybe in the high to medium risk category based on the number of folks who are actually running it in production. Having said all that, I'm ready to support your proposal on the semver basis. Your reasoning is sound. Thank you for writing your thoughts here and your effort to make it great. On Wed, Apr 22, 2020 at 11:32 AM David Davis <[email protected]> wrote: > I want to expound on my own reasoning behind why pulp_file should be > bumped to 1.0 because I realize my original email was probably too brief > and I apologize for that. > > The thing that I would refer to is semver.org which we've used as a guide > for versioning. semver.org defines a 0.Y release as: > > Major version zero (0.y.z) is for initial development. Anything MAY > change at any time. The public API SHOULD NOT be considered stable. > > Moreover, semver.org has this question/answer: > > How do I know when to release 1.0.0? > > If your software is being used in production, it should probably > already be 1.0.0. If you have a stable API on which users have come to > depend, you should be 1.0.0. If you’re worrying a lot about backwards > compatibility, you should probably already be 1.0.0. > > I think we meet both of these criteria. I expect that Pulp users are > probably using pulp_file in production already. In terms of its API, we've > had only two small features in the last couple releases of pulp_file since > 0.1.0[0] and no major changes to the public API (there was the rename of > one field). I don't foresee any major changes to the public api anytime > soon. There's not a roadmap for new features either and certainly nothing I > see that could cause major changes to pulp_file's API. > > I think that in this context it makes sense to bump it to 1.0 to > communicate to our users that the pulp_file API is stable enough to use in > production. > > Thoughts? > > [0] https://github.com/pulp/pulp_file/blob/master/CHANGES.rst > > David > > > On Wed, Apr 22, 2020 at 10:59 AM David Davis <[email protected]> > wrote: > >> I feel differently especially when considering that most other Pulp >> plugins are at > 1.0. Can you explain why you think pulp_file shouldn't be >> at 1.0? >> >> David >> >> >> On Wed, Apr 22, 2020 at 10:57 AM Brian Bouterse <[email protected]> >> wrote: >> >>> I've seen software live in the < 1.0 area for a long time and graduate >>> when it's in broad, production use. That's a difficult thing to assess >>> accurately, but to me, pulp_file hasn't reached that point. >>> >>> >>> On Tue, Apr 21, 2020 at 2:20 PM David Davis <[email protected]> >>> wrote: >>> >>>> With the next release of pulp_file, I'd propose we bump the version to >>>> 1.0. The pulp_file plugin has reached a level of maturity and stability >>>> that I think it could be considered production-ready. I've opened a PR to >>>> bump the version to 1.0.0: >>>> >>>> https://github.com/pulp/pulp_file/pull/380 >>>> >>>> Feedback welcome. I'll set a deadline of April 27, 2020. >>>> >>>> David >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
