[Pulp-dev] pulp_file 1.0

Matthias Dellweg mdellweg at redhat.com
Thu Apr 23 11:32:08 UTC 2020


I know it's a bit late to the party, but i think it is weird to have
pulpcore "stable" (whatever that means) and the reference implementation of
a plugin (which is pulp_file) held back. Especially so as pulpcore without
any plugin is rather useless.
You could use it as a dumb blob storage if you never called orphan_cleanup,
but that is not what we want it to be recognised stable for.

On Thu, Apr 23, 2020 at 1:16 PM David Davis <daviddavis at redhat.com> wrote:

> Sounds good, thank you for the feedback.
>
> If anyone has feedback, the deadline is April 27, 2020.
>
> David
>
>
> On Wed, Apr 22, 2020 at 1:01 PM Brian Bouterse <bmbouter at redhat.com>
> 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.
>>
>> 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
>>>>>>
>>>>> _______________________________________________
> 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/20200423/477e3f1d/attachment.htm>


More information about the Pulp-dev mailing list