On Wed, 2010-01-06 at 16:55 -0600, Eric Evans wrote:
> On Wed, 2010-01-06 at 16:33 -0600, Denny Abraham wrote:
> > This seems similar enough to the semantic versioning spec
> > http://semver.org/. (minus the third value) that it may be convenient
> > and worthwhile to implement the full spec.
>
>
On Wed, 2010-01-06 at 16:33 -0600, Denny Abraham wrote:
> This seems similar enough to the semantic versioning spec
> http://semver.org/. (minus the third value) that it may be convenient
> and worthwhile to implement the full spec.
The third value here is for "backward compatible bug fixes", (as
+1
This seems similar enough to the semantic versioning spec
http://semver.org/. (minus the third value) that it may be convenient
and worthwhile to implement the full spec.
On Wed, Jan 6, 2010 at 3:58 PM, Eric Evans wrote:
> On Thu, 2010-01-07 at 08:41 +1100, Ian Holsman wrote:
>> can you add a
On Thu, 2010-01-07 at 08:41 +1100, Ian Holsman wrote:
> can you add a new method api_version?
> some people will probably still want to know the version of the
> software being run, and it is still useful info to have for
> operational issues.
Yeah, you could, and that was what I had in mind initi
On Wed, 2010-01-06 at 13:40 -0800, Anthony Molinaro wrote:
> > What would be the rules governing that 3rd value?
>
> I usually like the first to be non-compatible changes, the second
> to be new functionality which is backward compatible and the third
> to be bugfixes. In the case of the .thrift
On Wed, Jan 06, 2010 at 02:47:26PM -0600, Eric Evans wrote:
> On Wed, 2010-01-06 at 14:29 -0600, Jonathan Ellis wrote:
> >
> > One question: do we need a 3-tuple?
>
> What would be the rules governing that 3rd value?
I usually like the first to be non-compatible changes, the second
to be new fu
Hi Eric.
can you add a new method api_version?
some people will probably still want to know the version of the software being
run, and it is still useful info to have for operational issues.
+1 on the numbering scheme.
as for breaking something that works (ie a client library), you can make the
On Wed, 06 Jan 2010 14:23:38 -0600 Eric Evans wrote:
EE> I'd like to propose a change to the way we version our API.
EE> Currently, we publish a version string via the thrift method
EE> get_string_property("version"). This version string always moves in
EE> lock-step with the current release, i
On Wed, Jan 6, 2010 at 2:47 PM, Eric Evans wrote:
> On Wed, 2010-01-06 at 14:29 -0600, Jonathan Ellis wrote:
>> The 0.5 api is a superset of the 0.4 one in method names and
>> arguments, but the exceptions declared are different, so client code
>> in compiled languages with checked exceptions (onl
On Wed, 2010-01-06 at 14:29 -0600, Jonathan Ellis wrote:
>
> One question: do we need a 3-tuple?
What would be the rules governing that 3rd value?
> The 0.5 api is a superset of the 0.4 one in method names and
> arguments, but the exceptions declared are different, so client code
> in compiled l
+1, the release version is only tenously related to the API version
and tracking the latter separately would be much more useful to
clients for the reasons you gave.
One question: do we need a 3-tuple?
The 0.5 api is a superset of the 0.4 one in method names and
arguments, but the exceptions decl
On Jan 6, 2010, at 1:23 PM, Eric Evans wrote:
> What does everyone think?
+1 from me.
--Joe
12 matches
Mail list logo
