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 <sven@stfx.eu> 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 <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.