Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Numbering scheme? #280

Closed
escowles opened this Issue Nov 27, 2017 · 15 comments

Comments

Projects
None yet
6 participants
@escowles
Copy link
Contributor

escowles commented Nov 27, 2017

Should the final recommendation be numbered? 1.0?

@awoods awoods added this to the Recommendation milestone Nov 27, 2017

@awoods awoods removed this from the Recommendation milestone Jan 10, 2018

@zimeon

This comment has been minimized.

Copy link
Contributor

zimeon commented Jan 10, 2018

I see two options:

  • The API spec is separate and new so we number it 1.0 where released
  • The API is tied to the next version of community Fedora so we number it 5.0

Although I see some community confusion with the former ("so Fedora 5.0 implements the API 1.0?") I think this is probably still the way to go. I imagine the community Fedora will do 5.0 5.1 5.2 while still following the first API recommendation, because there is much not specified in the API that would still require semantic versioning of the implementation. It would seem even more confusing to have Fedora 5.1.3 that implements the Fedora API 5.0 than it would have have 5.1.3 implements the Fedora API 1.0.

@awoods

This comment has been minimized.

Copy link
Collaborator

awoods commented Jan 10, 2018

👍 to the initial Recommendation being released as 1.0.0

@dannylamb

This comment has been minimized.

Copy link
Contributor

dannylamb commented Jan 10, 2018

Agreed. Other implementations will follow it too, so I don't see much sense in tying it to the community impl version.

@escowles

This comment has been minimized.

Copy link
Contributor Author

escowles commented Jan 10, 2018

👍 to 1.0.0

@dannylamb

This comment has been minimized.

Copy link
Contributor

dannylamb commented Jan 10, 2018

@zimeon zimeon added this to the Recommendation milestone Jan 10, 2018

@bseeger

This comment has been minimized.

Copy link

bseeger commented Jan 10, 2018

What would each letter in x.y.z mean in this case? Most specs seem to have a x.y scheme - so I'm curious as to what the z would represent. Thanks!

@escowles

This comment has been minimized.

Copy link
Contributor Author

escowles commented Jan 10, 2018

@bseeger I would expect to use the z level for trivial changes (typos, etc.)

@zimeon

This comment has been minimized.

Copy link
Contributor

zimeon commented Jan 10, 2018

@bseeger e.g. IIIF use of semantic versioning

@barmintor

This comment has been minimized.

Copy link
Contributor

barmintor commented Jan 11, 2018

@bseeger

This comment has been minimized.

Copy link

bseeger commented Jan 11, 2018

@zimeon, thanks for the info. I didn't realize that semantic versioning had entered the specification realm. To understand this better -- when someone's piece of software is compliant with a version of the spec -- will it just say it's compliant with the major.minor? How does this ripple into testing compliance in the Fedora API Test Suite? It's probably a separate question for maybe a different group, but it does make me wonder what level of compliance the test suite will test for -- will it be able to identify if something is, say, 1.0.0 compliant or, separately, 1.2.3 compliant? I realize that the PATCH changes will mostly be fixing typos, but I wonder what effect this would have on the test suite, if any. Mostly thinking out loud.

@escowles

This comment has been minimized.

Copy link
Contributor Author

escowles commented Jan 11, 2018

I'd expect the API Test Suite to be versioned with Major.Minor versions that match the spec and verify compliance with that (the Patch level shouldn't have any testable changes).

@awoods

This comment has been minimized.

Copy link
Collaborator

awoods commented Jan 16, 2018

@escowles : agreed. I would also expect the TCK to be testing at the specification major.minor granularity.

@awoods awoods self-assigned this Jan 24, 2018

awoods added a commit to awoods/fcrepo-specification that referenced this issue Feb 21, 2018

@zimeon

This comment has been minimized.

Copy link
Contributor

zimeon commented Mar 23, 2018

Propose close - done -- we agreed 1.0.0, this is implemented in #334, and is on the #330 release checklist

@escowles

This comment has been minimized.

Copy link
Contributor Author

escowles commented Mar 23, 2018

👍 to closing this issue, and merging #334 when we release 1.0

@awoods

This comment has been minimized.

Copy link
Collaborator

awoods commented Mar 26, 2018

Will be resolved with: #334

@awoods awoods closed this Mar 26, 2018

zimeon added a commit to zimeon/fcrepo-specification that referenced this issue Jun 14, 2018

barmintor added a commit that referenced this issue Jun 21, 2018

Stab at fixing fcrepo styles for candidate and recommendation (#375)
* Stab at fixing fcrepo styles for candidate and recommendation

* Address @awoods comments

* Change version to 1.0 to agree with discussion on #280/#334

* respec v14.0.13 cf #158
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.