It seemed like we were all in agreement so I went ahead and merged https://github.com/pulp/pulp_file/pull/380.
Thanks to everyone for the feedback. David On Mon, Apr 27, 2020 at 9:13 AM Daniel Alley <[email protected]> wrote: > +1 to 1.0 > > On Mon, Apr 27, 2020 at 5:57 AM Ina Panova <[email protected]> wrote: > >> Based on the extended reply from David referring to semver, I am in >> favour or releasing pulp_file 1.0. >> >> Also, comments inline. >> -------- >> Regards, >> >> Ina Panova >> Senior Software Engineer| Pulp| Red Hat Inc. >> >> "Do not go where the path may lead, >> go instead where there is no path and leave a trail." >> >> >> On Wed, Apr 22, 2020 at 7:02 PM Brian Bouterse <[email protected]> >> wrote: >> >>> 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. >>> >> >> Brian, this is a kind of chicken and the egg problem. Let's be fair and >> answer - how many folks will deploy something that is 0.y.z and not >> production ready? >> Not a lot of folks will deploy it in the production unless we release and >> say - this is stable enough for production use. Only after that we will >> have enough numbers to fairly say if it is low/high/medium risk software. >> >> >>> 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 >>> >> _______________________________________________ >> 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 >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
