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

Allow repacking templates of different compatible versions #379

Closed
destijl opened this issue May 19, 2016 · 2 comments
Closed

Allow repacking templates of different compatible versions #379

destijl opened this issue May 19, 2016 · 2 comments
Assignees

Comments

@destijl
Copy link
Contributor

destijl commented May 19, 2016

If you have 3.1.0.2 installed the repacker only looks for 3.1.0.2 templates, which is unnecessarily constrained since we support 3.1.* templates talking to the 3.1.* server.

Add a way to override this behavior.

@destijl destijl added this to the 3.1.0 Full Release milestone May 19, 2016
@destijl destijl self-assigned this May 19, 2016
@destijl
Copy link
Contributor Author

destijl commented May 19, 2016

More difficult than I thought:

can't just glob for available templates, or provide a --version option to config_updater because you then need to parse out what version you have, and change it everywhere: output filenames, pyinstaller metadata, deb package metadata etc. it's crazy complicated.

we could provide a --version option that just sets major minor etc. in the config system for the duration of the config_updater run, but we'd have to be careful to set the old values back. This is a fair bit of messing around that is equivalent to changing the version in .local.yaml running config updater, and then putting it back.

If you want to repack a different version I think the procedure is:

pip install the packages
copy your config over
change version to the one you want to repack
run config_updater to repack

that way you don't have to mess with your prod server config.

So I think we just continue to support the single template version for repacking. We need to release the templates before the server, so they should always be available.

@destijl destijl closed this as completed May 19, 2016
@destijl
Copy link
Contributor Author

destijl commented May 20, 2016

Reopening, since punting on this has created a problem:

If you need to update the client, you essentially have to also make a server release. Otherwise the latest templates can't be easily repacked by the latest server. Being forced to make a server release for a potentially minor client fix is not good. Since the components are part of the client package it's even worse: a server release every time you want to update a component. That's not workable.

What makes this hard is that we treat repacking like building and use the version number from the current config in lots of places. What we should really do is get the version number from the client template when repacking, so a 3.1.0.5 template repacked by a 3.1.0.2 server will be version 3.1.0.5.

We could split components into a separate repo, but this adds packaging overhead and there is already too much. Since all this saves you is copying templates from the previous release I don't think it's worth it.

@destijl destijl reopened this May 20, 2016
@destijl destijl removed the wontfix label May 20, 2016
@destijl destijl closed this as completed in cd7fd1f Jun 2, 2016
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

1 participant