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

Start versioning the repo and output #214

Closed
simonpoole opened this issue Nov 11, 2016 · 5 comments
Closed

Start versioning the repo and output #214

simonpoole opened this issue Nov 11, 2016 · 5 comments
Assignees
Labels

Comments

@simonpoole
Copy link
Contributor

I consider the issue that @tyrasd touched on in #206 , that we are not versioning at least the output, the most annoying thing about the current setup. Besides that having the unversioned output files in the repo itself is simply messy, it further makes it difficult to consume the output automatically without having to fear breakage (as we had with the transition to GeoJSON).

Is there any fundamental problem with say generating a (github) release per week if something has changed and uploading the generated files to the release section of github? Or any other versioned repo system that is belief system neutral (and no, I'm not a particular python fan, actually I just compared it to plague and cholera, one of them being another script language).

@iandees
Copy link
Member

iandees commented Nov 12, 2016

I do like the idea of building releases and putting the output somewhere outside the repo. I think we can convince Travis or Circle to generate the output and automatically post to GitHub Releases for us: https://docs.travis-ci.com/user/deployment/releases/ for example

@bhousel
Copy link
Member

bhousel commented Nov 12, 2016

Yes, I'd like these versioned and published to npm too.

I know we mentioned this in #179 (multiple types per source), which would be a breaking change. Is there anything else that we want to change about the schema soonish that would break compatibility?

package.json advertises this project as version 0.0.0, which means anything can change at anytime. But I think we should publish 0.0.0, make whatever breaking changes we want to, then publish 1.0.0 and start following semantic versioning thereafter.

@tyrasd
Copy link
Member

tyrasd commented Nov 12, 2016

anything else that we want to change about the schema soonish that would break compatibility?

Do we want to keep all three output formats? At least having both GeoJSON and JSON seems a bit redundant.

And if we really want to go all-in, we could think about how to support restricted imagery (like #192 and #194) where a client must display the user a modal window with the imagery's terms of use??

@simonpoole
Copy link
Contributor Author

vespucci currently consumes the JSON format and that wont change before 0.9.9, but I'm not sure if that is really a criteria given that I remove the WMS entries and minimize the result before including it in the build.

@grischard
Copy link
Collaborator

Is this still necessary with #385?

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

No branches or pull requests

5 participants