versioning transparency
flavorjones opened this issue · comments
Hello! Long time Hoe user here, first time issue filer.
It's not clear to me what's in a release of Hoe. There are no tags on the repository, and there are not releases in Github.
Can I ask that the maintainers please create git tags for versions, as is conventional across many Ruby projects?
Came here via Nokogiri..
@flavorjones Thought I'd lend you a hand in case you haven't figured it out by yourselves already.
The changes between v3.17.2 and v3.18.0 can be viewed here.
@ashmaroli Thanks for providing that link, my concerns are more around the lack of clarity of which commits are in which version of Hoe.
e.g, if I had commits for 3.17 and 3.18 I could git bisect more easily when trying to diagnose a bug like #96.
@flavorjones I understand your concern..
However, you can find the list of commits between v3.17.2 and v3.18.0 here.
Not sure, if they can help you bisect.
Thank you again, but I think you're still missing my underlying point which is that there is a lack of transparency about what commits are in what release.
Not at all Mike. I'm not countering your request for transparency here.
Just trying to help you come up with a patch for #96
More "transparency" would require more use of git, which I'm reluctant to do. Currently everything I do is synced up to git via a cronjob, which unfortunately isn't that smart. Tags and such (releases are just tags) aren't created.
Everything I do is regular and well documented. @ashmaroli probably came up with the commits to diff between by doing a git blame (or log) on History.rdoc. It's the last thing I modify before I do any release.
@zenspider What I did was git blame indeed but used the GitHub UI instead of the Command Line.
IMO, it shouldn't be this complicated to get a complete overview on what changed between releases.
@zenspider If you don't like the word "transparency" maybe we can substitute "obviousness"?
It sounds like your advice is: when I want to determine what commits are in which release, I should first go through the contents of the commits to History.rdoc (because the commit messages alone don't indicate what version is being prepped). Is that correct? That is moderately painful but I will work around it.
Side question: if you prefer to use perforce, what's preventing you from providing public access to your perforce repository? It feels like the primary challenge here is that your tooling isn't available to others.
This thread have given me an idea that might just be crazy enough to work.
Good job. @zenspider 🎉
Thanks, @zenspider, I very much appreciate it!