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

make it possible to get the version info from the API #10

Open
balmas opened this issue Mar 14, 2014 · 2 comments
Open

make it possible to get the version info from the API #10

balmas opened this issue Mar 14, 2014 · 2 comments

Comments

@balmas
Copy link
Contributor

balmas commented Mar 14, 2014

I'd like to be able to access the version information for the llt services, either via an API call or from the output

See also perseids-project/perseids_docs#25

@LFDM
Copy link
Member

LFDM commented Mar 14, 2014

Thought about something like that this week as well, but haven't decided on how to do it.
Initially thought about an extra API call, but it might be in order to include such info in the output as well - you'd want almost everytime anyway.

@LFDM
Copy link
Member

LFDM commented Mar 14, 2014

Some more thoughts, what exactly should e.g. a call to segtok return?

segtok lives inside the llt service and combines the output of the segmenter and the tokenizer, which both could have their own versioning (in fact, they have right now).

  • The most precise thing to do could be returning versions of all three parties involved.
  • The easy way out is that the llt gem determines the version number all all possibly dependent parts.

This is really only a problem in the initial phase though, where frequent bugfixes are still coming. Once this reaches some kind of stability this won't be a real issue anymore.
We haven't even reached version 0.1 yet ;)

Must add that the versioning is practically ineffective at the moment, as the deployed war is built directly from the respective master branches to avoid constant version bumping for little fixes, that are still valuable to have rather sooner than later (as in: waiting for a next release)
The radical thing to do would be to point any provenance data to specific git commits. This would certainly be the most precise way to rebuild data, but that might have practical implications.

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

2 participants