@Makyen Sorry, I've confused CVRG & URRS. Now both are working in FF. Btw, I suggest using git tags for version numbers and releases. Git branch names like URRS-Mak-CRUDE-tmp-hack and URRS-Mak-CRUDE-new-version are hard to track and maintain in the long run. Git branch names are for new features/testing (other people's work).
Marking version number "2.1.0.100" at a Git commitisn't the best Git practices.
I am currently learning to use Git by reading Pro Git. Right now I'm learning about branching and tags. My question is when should I use a branch and when should I use a tag?
For example, say I create a branch for version 1.1 of a project. When I finish and release this version, should I leave t...
@GNUSupporter8964民主女神地下教會 Yes, they are hard to maintain in the long run. I don't intend to do so. As to the URRS-Mak-CRUDE-tmp-hack branch, the intent is that the master branch will integrate everything that's needed for CRUDE, the other rooms, and potential expansion in one script, similar to what already exists for the CVRG and Archiver. The tmp branch, is intended to be just that: temporary. It exists because it was quicker to hack something together for CRUDE than do the full conversion for all rooms.
While some code in the URRS-Mak-CRUDE-tmp-hack branch will be kept, a significant portion of it will be thrown away and never merged into master. At the time I made the choice to use a branch for this, there was quite a bit of conversation in here wrt. how to handle completed requests and reducing the impact that a lack of information had on the time people spend attempting to service completed requests. Originally, SOCVR solved this, and other issues, by moving completed requests.
The URRS solves a considerable portion of those issues. I felt that the added impact of having to maintain that branch for an (inderterminite, but hopefully short) time and creating some effectively dead code was worth the benefit of having something available for CRUDE in a shorter time-frame.
The URRS-Mak-CRUDE-new-version branch is a relic of a very recently completed beta, which was held in it's own branch as it moved towards release. That branch was merged into master a short time ago. The branch will disappear as soon as enough time elapses for everyone to have been automatically upgraded to the release version. It's being maintained for a short time at the master HEAD for the convenience of anyone who hasn't been updated yet.
Note that the longer term betas are intentionally kept in their own branch until such time as the beta period is complete and then merged into master. Merging it into master prior to that point would result in every user who had previously installed the non-beta version from the head of master being automatically upgraded to the beta version by their userscript manager, even though they wanted to stay on the release version.
@GNUSupporter8964民主女神地下教會 I understand what you're saying, but I think you're misunderstanding what's going on. The version number in the code is controlling. It's used by userscript managers to compare against the user's installed version and trigger an update. It, thus, must change in the code. A the time the choice is made to make a release, everything else has already been committed and tested (i.e. loaded into various browser/userscript combinations at the commit prior to the version number change).
The only change left to do is roll the version number. Thus, we have commits that are only rolling the version number and the commit message says what the commit is doing (which is what a commit message is supposed to be). If there was a desire to be able to point people at a past version, then creating tags for different releases is certainly the way to go. We almost never need to link to older releases, so there has been no desire to create tags for versions.
@Makyen Thanks for your detailed explanation. I might understand you better if I read them several times more, but I think there're something that I've missed. Is there other chatroom/platform (say, GitHub issue) for this discussion? I'm asking you that so that we may focus on posts on Math.SE instead of version control for your awesome scripts. I should have made my previous comments on GitHub issue instead. Sorry for that.
@Makyen Maybe you want to hack this the 2nd time for another feather/bug fix. You may want to create a new Git branch for that. What would the name be? say, URRS-Mak-CRUDE-new-hack. So after a few hacks, you might end up with a bunch of indistinguishable branch names like URRS-Mak-CRUDE-new-hack, URRS-Mak-CRUDE-temp-hack, URRS-Mak-CRUDE-hack-temp, etc.
@Makyen Similarly, if you want to create new version after a merging a PR, how can the branch be named, after that the name URRS-Mak-CRUDE-new-version has been taken up?
I've come up with these questions after landing on the wrong branch.
The CRUDE version of the Unclosed Request Review Script (URRS) has been updated to Version 2.1.0.100 (GitHub) (install). It includes adjusting the tag colors, and a variety of other minor features and bug fixes.
I've come up with these questions while finding CVRG for installation on 2nd laptop, by clicking the "GitHub" link and then going up to the project root. The next day, I realized that I was on the wrong branch.
@GNUSupporter8964民主女神地下教會 I'm sorry that was an inconvenience. I don't have a good solution for that. Well, actually, the only solution I have for that which fits all the requirements, including that it's on the master branch, would have been to create a different file to use for the temporary version that is being used for CRUDE. However, without actually testing on the various userscript managers, that was, IMO, less likely to result in people being able to successfully auto-upgrade.
If it's any consolation, at least the CVRG would have auto-corrected your installation to be on the correct branch with the next version update. That, however, doesn't negate the issue.
@GNUSupporter8964民主女神地下教會 This seems like a XY question attempting to get me to think about something, but I'm not sure what. I'm interested, but not sure where the question is leading. As to another release for the CRUDE version, it would be (and was) the same branch name, which would result in people being automatically upgraded to the new version when their userscript manager checks the version at that URL. If someone submitted a PR for the CRUDE version, it would be merged into that branch.
As to the name for a new branch, I'd pick a name that reflects what's expected to happen in that branch prior to it being merged into master, or deleted.
@GNUSupporter8964民主女神地下教會 Again, I'm not sure what you're getting at. Branch names could be almost anything (within format limits). I try to use ones that are descriptive of what's intended to happen in the branch.
@Makyen The auto-upgrade issue would be at the time the CRUDE version becomes redundant (i.e. when all of it's functionality is in the main branch). Once the file would be deleted, the URL will 404. With using a branch, that branch name can be kept around for a time, allowing people to auto-upgrade to the then-current version.
@Makyen I hope I understand you correctly. In case of future releases, they will be released to branch URRS-Mak-CRUDE-new-version. Thanks again for response.
@GNUSupporter8964民主女神地下教會 np. I'm happy to discuss it. Your statement isn't quite what I'd intended.
There's no existing branch which is URRS-Mak-CRUDE-new-version, and unless you want it created, I don't intend to do so. My intent is that the HEAD of URRS-Mak-CRUDE-tmp-hack (i.e. where the URLs I've provided points to and will continue to point) is, and will remain, the most current version of the URRS for CRUDE (even if there are additional updates), until a few weeks after the changes are in the master branch that are needed for there to be a single version of the URRS which works in
all intended rooms. During those "few weeks" the URRS-Mak-CRUDE-tmp-hack branch and the master branch will be on the same commit, just with two branch names. After those "few weeks", which is after the timeframe which anyone semi-regularly using a browser which had installed from that URL would have had the script to auto-updated by their userscript manager,
the URRS-Mak-CRUDE-tmp-hackbranch will likely be allowed to remain at an earlier version that is also on the master branch, or the branch will be eventually removed. The goal is to permit autoupgrades by users to be as seamless as possible throughout the process of having this temporary hack to when the master branch includes all functionality for all intended rooms.
I'm definitely open to other possibilities, but I'd like to keep the goal of having autoupgrades work for users (as much as reasonably possible), so they don't have to manually reinstall from a newly provided URL.
