4.2.0-beta.3
rvilarl opened this issue · comments
@ronyeh I propose to make a beta once we merge the open PRs (#1537 #1540 #1541 #1546), and as you suggested make a general visual check to see what improved and if anything got worst.
@ronyeh @AaronDavidNewman @mscuthbert @sschmidTU any open issue that you would like to see addressed before the beta?
The PRs that I have done to reduce metrics and to remove TextFormatter should facilitate to use OTF directly in VexFlow5.
I'm happy to push a new beta in the next couple of days, even if we don't resolve all the pending PRs.
One big question is:
I feel like the current head revision is quite different than the last release, especially considering your work in reducing the reliance on metrics files.
In addition, we have introduced some visual differences that need to be reviewed.
I know VexFlow has never really followed semver, so I'm happy to call the next version 4.2 if others are OK with it.
However, it might be a surprise to some developers if upgrading from a 4.1 to 4.2 release changes the layout of their scores.
That said, we had some big plans for 5.0. Not sure the recent changes would really warrant a major version bump. But, if we were strictly following semantic versioning, I don't think we would have a choice but to bump it to VexFlow 5.0.
Thoughts?
Probably not very ortodox but I would continue with 4.2. Otherwise version 4 will be hard to maintain and I think we should for a while.
Or even less orthodox.... we skip 4.2 and bump it to 4.5, hahah.
Thanks. I will review some of the PRs today.
I understand concerns from @sschmidTU and others about removing the support for custom glyphs and font-specific metrics in 4.x.
I appreciate your work in making VexFlow conform better to the SMuFL standard. I agree that by VexFlow 5, we should be able to just use SMuFL fonts directly.
I think for the next 4.x release we should (at least) reintroduce the ability to apply font-specific metrics (in case a developer doesn't like a huge coda sign, for example). I can look into this. The defaults can be empty, of course. This would mean that we would use whatever is specified in the SMuFL font file.
Hi, I pushed a new beta: https://github.com/0xfe/vexflow/wiki/Release-Beta-4.2
npm i vexflow@4.2.0-beta.3
I think 4.2.0-beta has diverged quite a bit from 4.1.0. We need to document what has broken / changed, and possibly provide paths for developers to achieve (or approximate) the 4.1.0 look & feel, if they preferred it the old way.
Thanks. I will review some of the PRs today.
@ronyeh thanks a lot for the review and release! I have a suggestion, wouldn't it be better to place the built libraries in the release directory? We do not want to update the built libraries on all the intermediate commits, do we?
I understand concerns from @sschmidTU and others about removing the support for custom glyphs and font-specific metrics in 4.x.
custom glyphs are not removed in 4.x, they are there. And the font specific metric can be setup by any user just calling Font.load with a modified version of the metrics. We also have to resolve the problem form @AaronDavidNewman #1563
I appreciate your work in making VexFlow conform better to the SMuFL standard. I agree that by VexFlow 5, we should be able to just use SMuFL fonts directly.
It is doing it already in the vexflow5 branch :)
I think for the next 4.x release we should (at least) reintroduce the ability to apply font-specific metrics (in case a developer doesn't like a huge coda sign, for example). I can look into this. The defaults can be empty, of course. This would mean that we would use whatever is specified in the SMuFL font file.
As above, the user can call Font.load with modified metrics.
@ronyeh this is the concept I had. It doe not work though, we would need to have access to the font stack. I will make a PR in this regards
https://jsfiddle.net/3g0moxzt/1/
see #1567
@ronyeh I have created a branch vexflow4.1.x from label 4.1.0 (https://github.com/0xfe/vexflow/tree/vexflow4.1.x). There I have updated the npm packages and test files to be able to compare it with 4.2.0 beta 3. I find the changes fine I have used your compare tool. The Gonville coda is small.
I would only like to get #1567 merged and released to decide what we do with the metrics and finish with 4.0. My target is to get 5.0 with direct usage of fonts.
How the fonts look... Thanks again @ronyeh :)
@ronyeh @AaronDavidNewman @mscuthbert @sschmidTU I have already done a lot to get vexflow5 running. I would suggest to make a new branch vexflow5 and accept it as an alpha. Then we look into failures and review changes little by little. I would still leave vexflow4 as main branch in master.
@0xfe I would also like to appear in the copyright notice of vexflow5 together with you and others, I have invested a lot of time :). I also think that we should move to a organization. I would also place the GonvilleSmufl font there.
I also believe that vexflow5 should be considered a new product, the approach using the fonts directly is quite different and has a lot of impacts on metrics. This breaks some user applications.
What do we want to do now before we release?
I've moved 4.2.0 to RC status. No new features. Only bug fixes (i.e., if someone complains that we broke their vexflow integration).
https://www.npmjs.com/package/vexflow/v/4.2.0-rc.0
@rvilarl We should put together a wiki page to highlight the important (mostly font and layout related) changes in 4.2.0.
Thanks.