Citation Style Language

Versioning of CSL and the CSL spec

CSL Development
#31

I think yes; that style authors would really be on whatever latest versions, with preference to the latest x.x version.

#32

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.

Deprecating 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?

#33

For me, yes.

But we obviously need new input from @Sebastian_Karcher and @Rintze_Zelle1.

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.

#34

Or a development branch?

Concerning the rest, yes.

#35

I’m agnostic because I don’t entirely understand the implications of that decision for us. But if it makes sense, sure.

#36

Here’s an argument against develop that makes sense to me, and fits with where I was heading with this:

1 Like
#37

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.

#38

So, where are we now here? We’ll probably need a decision here to get on with the other issues.

#39

Yes, we’re frozen. Need input from @Frank_Bennett @Sebastian_Karcher @Rintze_Zelle1

#40

I’m contemplating merging the PRs in the next few days, and we can worry about version tags separately.

#41

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?

#42

My thought is if people want to validate against 1.0.1, they should validate against that tag?

1 Like
#43

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?

#44

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?

@bwiernik @Denis_Maier

#45

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.

1 Like
#46

@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.

#47

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.

#48

I haven’t had the bandwidth to follow that discussion, but will likely defer to whatever you two settle on.

1 Like
#49

It will be non-disruptive, like in text, so 1.0.x will be fine I think.

2 Likes
#50

Norm Walsh has brought up some issues of relevance to this discussion. Here’s his conclusion, and my reply.

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?