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

Spec development process #45

Open
constantinpape opened this issue Apr 26, 2021 · 8 comments
Open

Spec development process #45

constantinpape opened this issue Apr 26, 2021 · 8 comments

Comments

@constantinpape
Copy link
Contributor

I am a bit confused by the different versions of the spec that are stored in this repository:
We have the specs for the individual versions, right now 0.1 and 0.2 and we have latest.
Currently, 0.2 is further ahead then latest, because it contains the changes to the chunk layout from #40, which are not in latest yet.

In the future, I would propose a more structured dev process:
All changes are made against latest and only when we draft a new release, we copy latest to the folder for the corresponding version and add this with a separate commit (which only copies the spec and does not introduce any further changes).

cc @joshmoore

@joshmoore
Copy link
Member

Agreed, @constantinpape. This was my mistake because I was thinking you "owned" latest while I was making a non-breaking change. Something that hadn't been done before. The changes that just got merged to 0.2 will need backporting to latest. I can take care of that if you are not already in the middle of it.

P.S. It might be though that these static copies aren't ideal anyway and we want something less prone to conflicts.

@constantinpape
Copy link
Contributor Author

Agreed, @constantinpape. This was my mistake because I was thinking you "owned" latest while I was making a non-breaking change. Something that hadn't been done before.

Sure, no worries. Luckily the changes are still very manageable, so it's not problem right now to sync this manually.

The changes that just got merged to 0.2 will need backporting to latest. I can take care of that if you are not already in the middle of it.

I am in the middle of it already, see #46. I just need to sync the latest review changes later.

P.S. It might be though that these static copies aren't ideal anyway and we want something less prone to conflicts.

I think the static copies are fine, if we keep development strictly limited to latest.

@constantinpape
Copy link
Contributor Author

Ok, after looking at the review comments in #46: I guess it would be best to introduce
some placeholder for the version number in latest and then write a script that makes the copy and replaces the placeholder with the correct version.

@joshmoore
Copy link
Member

Hmm... on call, but I don't see an immedaite way to replace a variable. Files can be included if that would help: https://tabatkins.github.io/bikeshed/#including

@constantinpape
Copy link
Contributor Author

Hmm... on call, but I don't see an immedaite way to replace a variable.

Ok, I will have a closer look at bikeshed too and see if I can find something.
If there is nothing in there, we could also raise an issue about it.
Alternatively, it would be fairly easy to write some script for this ourselves (but we would need to introduce our own bikeshed flavor)

Files can be included if that would help: https://tabatkins.github.io/bikeshed/#including

Thanks for the pointer.

@joshmoore
Copy link
Member

Not to mention the need for this! ome/spec-prod@3fa5978

@sbesson
Copy link
Member

sbesson commented Feb 3, 2022

I assume this will be covered by the post-release item mentioned in #86

@constantinpape
Copy link
Contributor Author

I assume this will be covered by the post-release item mentioned in #86

Yes, that's the plan ;).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants