Catalog Entries

> On 18 Dec 2018, at 17:34, Ben Coman <[hidden email]> wrote:
>
> To understand for future reference, just curious what you ended up doing.
> At https://github.com/svenvc/ztimestamp/releases
> I see the v24 tag is commit ee31f06
>
> but at https://github.com/svenvc/ztimestamp/network
> I see the latest-release branch is commit b18dfdf
>
> It looks like you v24 of ConfigurationOfZTimestamp was committed after v24 tag was created.    
> Intuitively I'd expect the them to be the same commit.  Was there something impediment to doing that
> or you have a different idea?

> cheers -ben
>
> On Tue, 18 Dec 2018 at 23:42, Sven Van Caekenberghe <[hidden email]> wrote:
> Ben, Torsten,
>
> I decided to go for the branch option,
>
> https://github.com/svenvc/ztimestamp/tree/latest-release
>
> I will extend the ConfigurationOf to refer to it for Pharo 6.1 and 7
>
> Thanks for all the help.
>
> > On 18 Dec 2018, at 16:29, Torsten Bergmann <[hidden email]> wrote:
> >
> > Ben wrote
> >> "If the tag is edited on the server, but the local one is old"
> >
> > Yes - there could be an issue with this "tag moving" approach if the server is not checked
> > for new tags / moved tags and the version from the local repo cache is loaded - because
> > you might load an outdated while the server already has a newer "latest-release".
> >
> > When I think a second time I guess what Sven wants could maybe also be achieved with another
> > model:
> >
> > - having the "master" branch for development and tagged releases 1.0, 2.0, 3.0 and so on
> > - having a second "latest-release" branch where the current latest tag from master is just pulled/merged in
> >   Anytime you make a new release version in master you just pull it into this "latest-release" branch
> >
> > This has several benefits:
> >
> > - you can use the same stable load expression with stable URL: github://svenvc/ztimestamp:latest-release
> > - you just tag in master as usual
> > - when a new release was tagged in master you just switch to the "latest-release" branch, pull from master
> >   and push to github (easier than tag moving)
> > - the graph ("Insights" -> "Network") shows you if you already pulled the latest tagged version from master
> >   into the "latest-release" branch and also shows you how far ahead you are with master in case of further
> >   development
> >
> > Also when the latest release has some trouble but your master development is not yet ready for a full new version
> > you can hot-fix it in the "latest-release" branch to help people. Later when you are ready with another full new
> > version you will have the branches resynched then anyway.
> >
> > I'm not sure if this model also has some drawbacks - but as it looks now this seems a better option...
> >
> > Bye
> > T.
> >
> >
> >
> >
> >
> >
>
>

> On 19 Dec 2018, at 08:50, Alistair Grant <[hidden email]> wrote:
>
> Hi Sven,
>
> On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe <[hidden email]> 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.

>
>
>
> > On 19 Dec 2018, at 08:50, Alistair Grant <[hidden email]> wrote:
> >
> > Hi Sven,
> >
> > On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe <[hidden email]> 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.

> On 19 Dec 2018, at 10:58, Alistair Grant <[hidden email]> wrote:
>
> Hi Sven,
>
> On Wed, 19 Dec 2018 at 10:46, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>>
>>
>>> On 19 Dec 2018, at 08:50, Alistair Grant <[hidden email]> wrote:
>>>
>>> Hi Sven,
>>>
>>> On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe <[hidden email]> 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?