I think yes; that style authors would really be on whatever latest versions, with preference to the latest x.x version.
Ok, thinking a bit more about it I guess you’re right. If we want a painless update, the next version should be 1.0.2.
What is more, I now think the approach taken by the CSL 1.0 Specification Update 2010-05-30 that I’ve already quoted above is right (although the distinction between minor and major incompatibilities is not quite clear.)
So, the new in-text feature should be on 1.0.3. (It is backwards compatible.)
The next additional backwards compatible feature is 1.0.4. etc.
choose would perhaps be a good candidate for a 1.1. release. It’s backwards incompatible, but it’s perhaps still a minor incompatibility.
Changing the datamodel from flat to hierarchical may be considered a major incompatibility, so that would be 2.0.
Does that look feasible?
For me, yes.
In this model, we would just submit PRs against master, and keep version number constant, and the decisions would be how to sequence the merges and when to tag a 1.0.x version.
So logically, merge the low-hanging fruit of the straightforward variable and item type changes first, tag 1.0.2, then intext and tag 1.0.3.
Then do the same with docs, etc.
Or a development branch?
Concerning the rest, yes.
I’m agnostic because I don’t entirely understand the implications of that decision for us. But if it makes sense, sure.
Here’s an argument against develop that makes sense to me, and fits with where I was heading with this:
I have no strong opinions here. I’m ok with both approaches.
Only a question: If we merge directly into master, doesn’t that mean that style authors always have to check out a specific tag? Or we can only merge immediately before a new release.
So, where are we now here? We’ll probably need a decision here to get on with the other issues.
I’m contemplating merging the PRs in the next few days, and we can worry about version tags separately.
Basically good for me. But then current master will be ahead of 1.0.1. Will that cause trouble if someone validates against that schema version?
My thought is if people want to validate against 1.0.1, they should validate against that tag?
Main problem I see is the sequence of the commits would then constrain the tagging. As in, if I merged intext first, that would pretty much require it be part of same tag is the more minor changes.
I guess unless we rewrite the git history, which is possible, but maybe a little risky?
I merged the variable and type addition commits.
I believe I wrote the commit messages such that all linked issues are now closed.
Any other minor changes along these lines we want to add now?
On the intext PR, I had to do some git surgery to fix it. Can you two take another look?
I will take a look at intext. There are a few more variables that I think we can add in the minor release. I will open a new PR.
@Dan_Stillman - any input on this?
Not sure what other implementers are around here, but now would be the time to speak up for those folks.
To update, I’m waiting on @bwiernik’s PR, and then plan to merge that and then the new intext element PR.
I haven’t decided yet if I’ll bundle all of this in one 1.0.2 tag, or split the latter off to 1.0.3; or simply leave master untagged for now and we can decide later.
What do you think about also adding the split title feature to 1.0.2 or to 1.0.3 together with the intext element? I think we already have a pretty sound proposal.
I haven’t had the bandwidth to follow that discussion, but will likely defer to whatever you two settle on.
It will be non-disruptive, like in text, so 1.0.x will be fine I think.
If we followed his suggestion, I think we’d do a 1.0.x release with the new variables, etc., and then a 1.1 release with the changes he suggests (and maybe intext?).
We could bundle 1.1 with a formal “processing” spec or supplement, that would probably necessarily (because of time) have to start off small?