On Sunday, 15 March 2015 at 07:23:11 pm +0100, Élie Roux wrote: ...trimmed for brevity... > > 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?
I think that'd be a great way to do it. > > 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. > Both models (and probably many others) are equally valid, so the decision is really based on your concerns. If you think the master should be the bleeding edge in order to keep things easy and encourage contribution, using Br. Samuel's suggestion, then I would additionally suggest the use of a "stable" tag on the current stable version, so that someone checking out the git repository doesn't have to actually inspect the repository to "git checkout" the stable branch. Alternately, something I have done in the past is this: Have two repositories (not branches): gregorio and gregorio-beta. You work in gregorio-beta, and when that stabilizes, merge it into gregorio and label it with the version number. Bug fixes against the stable version go in gregorio, are labeled with a patch version, and merged into gregorio-beta. Rinse and repeat. Create branches in gregorio-beta for experimental features that are several versions ahead, if necessary. Contributions are generally made against gregorio-beta, but even if they were made against gregorio, they can be pulled into gregorio-beta instead. Unless you need a feature branch, there are no branches to maintain. Instead, one or the other repository is ahead of the other, but that's easy with git. People who want stable check out gregorio and people who want beta check out gregorio-beta. If you ever want to support multiple stable versions simultaneously, you can either clone the gregorio repository for each stable version or choose to use branches at that point. However, I don't think Gregorio is big enough to support multiple stable versions. Again, this is just another idea. > > 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... The obviously easiest things to find would be compile problems. As for comparing output, the PDFs cannot be compared directly because of the creation date and modification date values embedded within the PDF itself. I was thinking of using imagemagick to compare, but I still have to work that out. > > > I can try to set this up, if you would like me to. > > Please I'll get started and keep you posted. > > Thank you, > -- > Elie > Regards, Henry _______________________________________________ Gregorio-users mailing list Gregorio-users@gna.org https://mail.gna.org/listinfo/gregorio-users
