> It would let users know how much of a > change they have coming when upgrading. As I have mentioned in an > earlier email, it makes it easy to decide if you are willing to "risk" > an upgrade given your current situation.
I plead guilty for that, making a release was too much work for me, especially since I have to rely on people who don't always have time for the Mac package. So I basically did not make enough releases. Now it's changing a little, especially since Br. Samuel is helping a lot and is less affraid to release than me. > 2. Have the code take the argument to \includescore and use that to > decide which way to go. If there is no extension or a .gabc extension, > then do things the new way. If there is a .tex extension, do things the > old way. Agreed, again, I should have inspected the pull request more carefully and have more tested, which I didn't. I agree there needs to be a more backward-compatible way to do that. > Practically speaking, had this been backward compatible, issue #83 would > not have occurred. In this case, it also would have been one less thing > for the Gregorio maintainers to maintain. Agreed. > As I've said before, I think Gregorio should have an upgrade "cheat > sheet" for major versions. Agreed. What you're refering to is, I believe, usually called "Migration guide". Maybe a wiki page on github would be good? > Especially incrementing the major version, but perhaps when incrementing > the minor one as well, some users can tolerate being on the bleeding > edge whereas some users would like stability. This can be handled with > good tagging, release, and snapshot builds, etc., but (being a Linux > user where the only option is really to install the git version) I > propose the beta branch approach. We're currently clarifying the git workflow, I agree it was extremely unclear. What we now have in mind is the following (quoting Br. Samuel): " When we decide to do a release, we fork a new branch called (for example) release-3.0. We then tag the branch as v3.0.beta. After testing, documentation updates, bugfixing, etc. We add a new tag v3.0.0 at the head of the branch as the official release. Should we then find the need to patch the release, we do so and tag the new head as v3.0.1, etc. Meanwhile, development of features continues on master (as you suggested), and all fixes to the release-3.0 would be merged back into master as needed. When we decide it's time for a new release, we create branch release-3.1 and repeat the process. This gives us one less branch to worry about while still keeping things relatively clear. " It seems relatively simple and, if we do things in a proper way, should give less problems: release-3.0 (in the example) would be beta, and master would be experimental. What do you think? I originally proposed a more complex workflow with a beta branch, but it requires quite more work... > When developing new, especially incompatible, changes, do this in a beta > branch (either a named non-master branch in the current repository or > another clone of the repository). Make all the changes in the branch, > and after it's had time to stabilize, merge it into the master branch. You're right, it seems I was a bit confused a thought master was always bleeding edge... but you're right. I kind of like this workflow http://nvie.com/posts/a-successful-git-branching-model/ but it's quite a lot of maintenance, and might discourage external contributions... So I think we should find the right balance between ease of maintenance and being precise enough for users using a git version. > As of right now, the master branch of the main repository has been > broken for a few days running against a major project that I'm working > on. I am willing to be on the bleeding edge, so that's fine, but if I > weren't, it would be nice if the default branch (master) of the git > repository was stable and working. Agreed. One of the reasons I passed the project to github was the ease of branching (it also exists on svn, but is really a pain), so I definitley agree we should leave unstable code in branches. > I think there should be a repository of test scores that need to pass > (or be made to pass) before unleashing a new version of the Gregorio on > the unsuspecting public. That would be great, indeed. > In the past few days, I've come up with a number of minimum working > examples (based on my large project) that I've used to report issues. > It would be nice to place these into a subdirectory of the Gregorio > repository with a way to run them against the currently checked-out > version of the software, or if that is not desired, in a different > repository. Maybe in a different repository. But a big difficulty is to know how to pass a test... do you compare pdfs? Do you compare tex code? Do you check all tests by hand? With unit tests that take hours to run, you can be pretty sure they'll almost never be run... So, though I agree with the theoretical benefits of unit tests, it might be difficult to run in this case... So I agree on the idea, I'm just curious about how you would see them... > I can try to set this up, if you would like me to. Please Thank you, -- Elie _______________________________________________ Gregorio-users mailing list [email protected] https://mail.gna.org/listinfo/gregorio-users
