-
Notifications
You must be signed in to change notification settings - Fork 54
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
Follow Semantic Versioning #47
Comments
This came up very briefly at our last meeting. We broke the SemVer semantics by dropping support for the I am interested in this idea and exploring it more. There would be a question of how to migrate to this method of naming from our current method. Three proposals for the image API:
@azaroth42, @zimeon, @snydman: thoughts? |
Really, we're 1.2 with the pixels API and (IMO) 2.1 with the subsidiary I understand the dependency management requirement, but the additions to me Basically ... I think we stick to our current scheme as the changes in the On Mon, Mar 10, 2014 at 6:59 AM, Jon Stroop notifications@github.comwrote:
|
Actually, we're 1.0.2 with the pixels as the changes are just documentation R On Mon, Mar 10, 2014 at 8:20 AM, Robert Sanderson azaroth42@gmail.comwrote:
|
Sorry, what were the "pixels API" changes? Is this something that predates my involvement? Right now if I see Going forward, we've added the So, going forward, I agree with you, but IMO we're at 3.0.0-alpha right now. |
On Mon, Mar 10, 2014 at 9:21 AM, Jon Stroop notifications@github.comwrote:
R |
On 03/10/2014 12:28 PM, azaroth42 wrote:
Gotcha, OK.
What I proposed is that profile and context URIs only reflect the major
Not if you're following the spec. The only contract the spec is making, |
Sorry, one more addition. The other stable URI in the game here is the Base-URI for your image. Most of the practical linked data applications I can imagine (e.g. the relationship between the Metadata API and the Image API) would be dependent on that URI not changing; not the context or profile. |
Very true. On Mon, Mar 10, 2014 at 9:47 AM, Jon Stroop notifications@github.comwrote:
|
So, thoughts about the URIs only reflecting the major field in the SemVer revision number? |
Yes. Fewer URLs are better. Look how Google fails on maintaining the Google Maps Javascript Reference. The deprecated version URL is broken (404).
Same approach in the Angular Reference, lot of 404s. This is bad.
Yes. You would simplify things, if the image and the meta API share the same version. # current
api/
|__ image/
|__ spec/
|__ compliance/
|__ meta/
|__ spec/
|__ compliance/
# latest 1.x.y
api/
|__ 1/
|__ image/
|__ spec/
|__ compliance/
|__ meta/
|__ spec/
|__ compliance/
|
Btw, the link
is broken. |
Is it considered broken if it never worked in the first place? 😿 See #2. |
One more comment for versioning. Git allows branches in submodules. You can write the specs in this repository and just include the different branches in the website repository. |
Concrete proposal from someone who cares, or close with wontfix ? |
I submit #1 in my post way up the page as a proposal. |
What are the URIs if there are two versions? It seems pointless to re-number a version to me. However, that's not to say that the next version of presentation API isn't 3.0.0 while image api is 2.0.1 as there might be big changes to one and not to the other. Also search and annotation can't start at 2.0.0. Unless there's a practical advantage to aliasing that I'm missing? |
I'd support that (ie just start). And URIs only reflect the major version. |
I agree that there is no benefit in renumbering/aliasing past versions. If we do this we just start. Seems to me it makes sense only if we do it for all IIIF specs. I assume that is what is imagined? |
All specs, individually, right? Eg the search API will start at 1.0.0, at the same time as the presentation and image APIs being at 2.X.Y If the URIs only reflect the major version, what happens to the previous minor and patch version documents? They get moved to a different URI, but the latest version is always at major? |
I think we stick to the major version in the URI for the latest and put the semver number somewhere somewhat prominent near the top of the spec. Once a version is no longer the latest we just use the full semver number (What's the thought behind the extra '2/' above?). |
I agree that version numbers are specific to each spec. What I meant by "all IIIF specs" is that we should not apply this scheme to a subset (such as just image), I think we need to be consistent and do semantic versioning for all specs. This might mean that we should expand the number of people we consult to get buy-in from. There are some implications for PR here (e.g. desire to hide breaking changing behind non-semantic versioning). I would think URIs would be like |
Shall we take it to IIIF-Discuss? On Fri, Mar 21, 2014 at 9:17 AM, Simeon Warner notifications@github.comwrote:
|
Sure. And Tom as well, I think. On Fri, Mar 21, 2014 at 9:27 AM, Jon Stroop notifications@github.comwrote:
|
Am writing it up (unless one of you has already started?) |
Done. |
For posterity, we added this section to the Image API: 1986464#diff-381a219298e27a83caa34173bf7eba82R523 |
What do you think about following the Semantic Versioning?
The text was updated successfully, but these errors were encountered: