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.
