[Pulp-dev] pulp_file 1.0

[Brian Bouterse]

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 <daviddavis at redhat.com> 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 <daviddavis at redhat.com>
> 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 <bmbouter at redhat.com>
>> 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 <daviddavis at redhat.com>
>>> 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
>>>> Pulp-dev at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200422/edf533dd/attachment.htm>