Re: release process for 1.1 libraries?

> On 7 Feb 2018, at 22:03, Robert Sanderson <azaroth42@gmail.com <mailto:azaroth42@gmail.com>> wrote:
> 
> 
> +1 to releasing the libraries. If a WG decides to break a well adopted feature (hopefully for good reasons) then it's a clear indication of a 2.0 rather than 1.1.

I would be a little bit cautious with such statements. This statements is true when it comes to JSON-LD 1.0 features. But JSON-LD 1.1 is still a draft and "only" (do not take it as a derogative term!) and input to a WG; i.e., any 1.1 feature should be considered as experimental, and adopters should be aware of that.

> 
> Semantic versioning on the library and clear documentation as to which features are 1.1 and hence to be treated with some caution at this stage, seems like ample warning that things might change.

+1

Ivan

> 
> Rob
> 
> 
> On Wed, Feb 7, 2018 at 11:03 AM, Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>> wrote:
> > On Feb 7, 2018, at 10:46 AM, David I. Lehn <dil@lehn.org <mailto:dil@lehn.org>> wrote:
> >
> > Hi,
> > What do people think about releasing libraries with 1.1 draft spec support?  Gregg Kellogg has done some great work adding 1.1 support to jsonld.js and pyld.  We'd like to release that code for people to use but I'm unsure on how to best do it.  Once the code is out there people will start using and depending on the features.  If changes need to be made before 1.1 is final, it would be nice to be able to change anything as needed.
> >
> > Libraries can use a semantic versioning scheme, and if the spec changes, that will bump up the version.  But how do we deal with the JSON-LD data itself?  We want to avoid needing tricky compatibility code for possible old draft behavior.  Is this enough of a problem to even need a solution?  "@version": "1.1-draft-1" or similar might be nice, but that doesn't have the 1.0 processor fail behavior.  "@version": [1.1, "draft-1"] could work, and arrays would even allow a string "1.1" version, but maybe that's too confusing.  Other schemes are possible too, for 1.1 processor to read other flags, etc.  Thoughts?
> 
> People have been using my Ruby JSON-LD library for a while, which has these issues released. Indeed, semantic versioning is a way to introduce a breaking change to the library, but you have a point about people creating data which relies on this.
> 
> Not sure about putting more semantics in @version. If the eventual WG decides to break compatibility with CG 1.1 issues, then they would likely need to signal this with a different version number.
> 
> > The easiest thing to do is release the libs, and document that all 1.1 features are for draft specs and subject to change.  User beware.
> 
> In whatever state, I think the libraries need to be released, if only as a pre-release, as people do rely on features such as id maps now, and likely other features.
> 
> Gregg
> 
> > -dave
> 
> 
> 
> 
> 
> --
> Rob Sanderson
> Semantic Architect
> The Getty Trust
> Los Angeles, CA 90049


----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>