> On 19 Dec 2018, at 10:58, Alistair Grant <[email protected]> wrote:
>
> Hi Sven,
>
> On Wed, 19 Dec 2018 at 10:46, Sven Van Caekenberghe <[email protected]> wrote:
>>
>>
>>
>>> On 19 Dec 2018, at 08:50, Alistair Grant <[email protected]> wrote:
>>>
>>> Hi Sven,
>>>
>>> On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe <[email protected]> wrote:
>>>>
>>>> I know about master and what it means, but that is not exactly what I want.
>>>>
>>>> When you release, that is a deliberate action: you put a stamp on the
>>>> current project timeline, declaring it as ready/stable enough for people
>>>> to depend on.
>>>>
>>>> The master branch can further evolve after a (latest) release. It is the
>>>> next release candidate.
>>>>
>>>> I would like to depend on whatever released version is the latest. See the
>>>> URLs in my previous email.
>>>
>>> I think your understanding of master is different from mine. master
>>> should never be the next release candidate, it is only ever the latest
>>> GA code.
>>>
>>> In that case, you can use master to mean "the latest GA version".
>>>
>>> If you want release candidates, they should be branches off
>>> development (or tags).
>>>
>>> If you want to support multiple versions, e.g. be able to release a
>>> 4.1 after 5.0 has been released, then each version should be branched
>>> off master (at the GA commit for that version).
>>>
>>> If you want to know where a named GA version is (and there won't be
>>> further updates), it is a tag on the master branch.
>>
>> I don't think/believe there is only one right way to use git, that is part
>> of its power.
>
> Agreed, and I can see how you read my reply that way, but I didn't
> mean to imply that "this is the one and only right way to do it".
>
>
>> In our eco system, with #stable and #bleedingEdge / #development versions of
>> ConfigurationsOf, it is my experience that very few people test before
>> something is released. Hence the only way to get feedback is to release.
>> Only if something has proven itself to be stable for some time can it
>> receive a release tag, IMHO.
>
> OK, so what I understand you're try to achieve is to have a "released"
> version and a "released and better tested" version.
>
> Doesn't this run the same risk of people just sticking to the
> "released and better tested" version, so the "released" version never
> gets the additional testing that's desired?
Yes, that is the question ;-)
>> I also want to make things as simple as possible.
>
> :-)
>
> Cheers,
> Alistair
