On 28 May 2014, at 17:14, Sergey Lukjanov slukja...@mirantis.com wrote:
1. How should we handle addition of new functionality to the API,
should we bump minor version and just add new endpoints?
Agree with most of folks. No new versions on adding new endpoints.
Semantic changes require new
Bunch of responses/thoughts:
API
I'm ok that semantics additions could be done in one API version w/o
increasing minor version. I like the idea to keep only major API
versions starting from the next API version.
RE backward compat period, for now 1-2 cycles is ok.
Images
Agreed that we
So, it looks like we have an agreement on all question.
There is only one technical question - keeping release images means
that we need to keep the whole matrix of images: plugin X version X
OSy [X root-passwdord]. I'll take a look on total size of them and
ability to publish them on OS infra.
On 05/29/2014 10:22 AM, Sergey Lukjanov wrote:
So, it looks like we have an agreement on all question.
There is only one technical question - keeping release images means
that we need to keep the whole matrix of images: plugin X version X
OSy [X root-passwdord]. I'll take a look on total size
On 29 May 2014, at 18:43, Matthew Farrellee m...@redhat.com wrote:
i do not think we should release any images that have a root password set
(essentially a backdoor).
for K we should deprecate the hadoop1 versions and thus significantly cut the
size of the new image artifact.
Agree
Hey folks,
it's a small wrap-up for the two topics Sahara backward compat and
Hadoop cluster backward compatibility, both were discussed on design
summit, etherpad [0] contains info about them. There are some open
questions listed in the end of email, please, don't skip them :)
Sahara backward
- Original Message -
Open questions
1. How should we handle addition of new functionality to the API,
should we bump minor version and just add new endpoints?
I think we should not include the minor revision number in the url. Looking at
some of the other projects (nova,
On 05/28/2014 09:14 AM, Sergey Lukjanov wrote:
Hey folks,
it's a small wrap-up for the two topics Sahara backward compat and
Hadoop cluster backward compatibility, both were discussed on design
summit, etherpad [0] contains info about them. There are some open
questions listed in the end of
On 05/28/2014 01:59 PM, Michael McCune wrote:
- Original Message -
Open questions
1. How should we handle addition of new functionality to the API,
should we bump minor version and just add new endpoints?
I think we should not include the minor revision number in the url.
Looking
for juno we should just have a v1 api (there can still be a v1.1 endpoint,
but it should be deprecated), and maybe a v2 api
+1 any semantic changes require new major version number
+1 api should only have a major number (no 1.1 or 2.1)
In this case we will end up with new major number each
On 05/28/2014 03:50 PM, Andrew Lazarev wrote:
for juno we should just have a v1 api (there can still be a v1.1
endpoint, but it should be deprecated), and maybe a v2 api
+1 any semantic changes require new major version number
+1 api should only have a major number (no 1.1 or
11 matches
Mail list logo
