>> IMHO, that change is too important for a 2.4... it would require a
>> 3.0 because it is not just adding features, it is also breaking all
> >old scores. 2.4 should properly compile all files created with 2.x
> >which won't be the case if I understood well.
>
>For what it's worth, I agree with this opinion.  If scores created
>before the change won't work after the change (and vice versa) then a
>change to last part of the version number just doesn't capture the
>severity of the shift.

>At the same time, the underlying architecture in the code hasn't
>changed, meaning that a change to the main version number seems overkill.

I>f we had a three tiered version number, I'd say this warranted a middle
>number change (as the underlying architecture hasn't changed).  Might it
>be worth switching to a three tiered version number in order to handle
>this, or are we so far along that we need to live with a two-tiered system?


Might want to look into, and potentially adopt, semantic version numbering:
http://semver.org

But even with a three-tiered numbering system, something that breaks old
scores would need to bump the major (first number).
X.Y.Z rc

X - Major - Increments if any existing features are broken, or things
written for it stop compiling properly.
Y - Minor - New features added.
Z - Patch - Bug fixes
(rc - release candidate)


A project is never too far along to adopt good practices.


Cheers.
-Adam Michael Wood






On Wed, May 7, 2014 at 5:00 AM, <[email protected]> wrote:

> Send Gregorio-devel mailing list submissions to
>         [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.gna.org/listinfo/gregorio-devel
> or, via email, send a message with subject or body 'help' to
>         [email protected]
>
> You can reach the person managing the list at
>         [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gregorio-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: [Gregorio-commits] r1332 - in /trunk: fonts/
>       plugins/gregoriotex/ tex/ (Br. Samuel Springuel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 06 May 2014 14:40:28 -0400
> From: "Br. Samuel Springuel" <[email protected]>
> To: [email protected]
> Subject: Re: [Gregorio-devel] [Gregorio-commits] r1332 - in /trunk:
>         fonts/ plugins/gregoriotex/ tex/
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 2014-05-06 3:43 AM, Olivier Berten wrote:
> > IMHO, that change is too important for a 2.4... it would require a
> > 3.0 because it is not just adding features, it is also breaking all
> > old scores. 2.4 should properly compile all files created with 2.x
> > which won't be the case if I understood well.
>
> For what it's worth, I agree with this opinion.  If scores created
> before the change won't work after the change (and vice versa) then a
> change to last part of the version number just doesn't capture the
> severity of the shift.
>
> At the same time, the underlying architecture in the code hasn't
> changed, meaning that a change to the main version number seems overkill.
>
> If we had a three tiered version number, I'd say this warranted a middle
> number change (as the underlying architecture hasn't changed).  Might it
> be worth switching to a three tiered version number in order to handle
> this, or are we so far along that we need to live with a two-tiered system?
>
> >> Hmmm, changing the name of the fonts it, I believe, a bad idea, but
> >> I'll try to find a mechanism to find the version of a font...
>
> > If people are using these fonts elsewhere or simply if they want to
> > edit an older pdf, the new fonts will break it if they replace the
> > old ones. I think the new fonts should be called something like
> > "greciliae new" or "greciliae 3" for compatiblity with several years
> > of works already created with Gregorio. I think it's a very very bad
> > idea to give 2 fonts the same name if they don't give the same
> > result.
>
> I'm torn on this one, too.  The fact that the glyph remapping means that
> documents which were intelligible before the change will be
> unintelligible after the change implies to me that we need to mark that
> prominently and changing the font name certainly does that.
>
> On the other hand, all the change does (if I understand it correctly) is
> move the glyphs from one code range (where they shouldn't have been in
> the first place, according to the standards) to another.  The glyphs
> themselves are the same so we don't really have a new font.
>
>
> So, yeah, I guess I don't have anything really definitive to add to this
> discussion.  Here are my thoughts anyway, in case they're useful to
> someone else in ironing out their own.
> ?????????????????????????
> Br. Samuel, OSB
> (R. Padraic Springuel)
>
> PAX ? ???????
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Gregorio-devel mailing list
> [email protected]
> https://mail.gna.org/listinfo/gregorio-devel
>
>
> ------------------------------
>
> End of Gregorio-devel Digest, Vol 57, Issue 3
> *********************************************
>
_______________________________________________
Gregorio-devel mailing list
[email protected]
https://mail.gna.org/listinfo/gregorio-devel

Répondre à