[Pulp-dev] pulp_file 1.0

Tue Apr 28 14:43:56 UTC 2020

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 <dalley at redhat.com> wrote:

> +1 to 1.0
>
> On Mon, Apr 27, 2020 at 5:57 AM Ina Panova <ipanova at redhat.com> 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 <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.
>>>
>>
>> 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 <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
>>>
>> _______________________________________________
>> 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/20200428/1ca1d416/attachment.htm>