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 <astares@gmx.de> 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.
>
>
>
>
>
>