You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Jake Farrell <jf...@apache.org> on 2016/01/09 18:46:53 UTC
Thoughts on a 0.9.4 rc
What does everyone think about cutting a 0.9.4 release candidate in the
next week or so?
-Jake
Re: Versions, patches and limited resources (was: Thoughts on a 0.9.4 rc)
Posted by Yuxuan Wang <yu...@reddit.com.INVALID>.
+1 to what Allen said.
Regarding 1.0, the main problem is backward compatibility expectations from
semantic versions. With so many languages supported in thrift, basically if
we ever make any breaking change from any of the language libraries we need
to bump the major version to comply with semver, which can be problematic.
On Sat, Mar 5, 2022 at 6:41 PM Allen George <al...@gmail.com> wrote:
> Hi Jens -
>
> First off, thank you so much for your work on Thrift. You've been a
> consistent maintainer for as long as I've been a member of this community.
>
> I think it's less a question about versions, and more about expectations.
> Thrift has two major challenges: a wide language footprint (which means
> that maintainers have to understand N different
> languages/tools/build/publish systems) and a fairly thin maintainer base.
> Given that, I suggest that we support at most the last released version, as
> well as what's in the main/master. I understand that this may cause
> inconvenience to the user community, but I think that users can choose to
> fork the codebase and generate/use the artifacts they need for the older
> versions they're using.
>
> Best,
> Allen
>
> On Sat, Mar 5, 2022 at 1:31 PM Randy Abernethy <ra...@rx-m.com>
> wrote:
>
> > If the community wants to move to 1.0 I would support that.
> >
> > On Sat, Mar 5, 2022 at 3:11 AM Jens Geyer <je...@apache.org> wrote:
> >
> > >
> > > Am 05.03.2022 um 12:06 schrieb Jens Geyer:
> > > > Java and the compiler (for C#)
> > >
> > >
> > > Well, compiler code is a full package ... so that would then be a full
> > > 0.16.1 indeed.
> > >
> > >
> >
> > --
> >
> > Randy Abernethy
> > Managing Partner
> > RX-M, LLCrandy.abernethy@rx-m.com
> > o 415-800-2922
> > c 415-624-6447
> >
>
Re: Versions, patches and limited resources (was: Thoughts on a 0.9.4 rc)
Posted by Allen George <al...@gmail.com>.
Hi Jens -
First off, thank you so much for your work on Thrift. You've been a
consistent maintainer for as long as I've been a member of this community.
I think it's less a question about versions, and more about expectations.
Thrift has two major challenges: a wide language footprint (which means
that maintainers have to understand N different
languages/tools/build/publish systems) and a fairly thin maintainer base.
Given that, I suggest that we support at most the last released version, as
well as what's in the main/master. I understand that this may cause
inconvenience to the user community, but I think that users can choose to
fork the codebase and generate/use the artifacts they need for the older
versions they're using.
Best,
Allen
On Sat, Mar 5, 2022 at 1:31 PM Randy Abernethy <ra...@rx-m.com>
wrote:
> If the community wants to move to 1.0 I would support that.
>
> On Sat, Mar 5, 2022 at 3:11 AM Jens Geyer <je...@apache.org> wrote:
>
> >
> > Am 05.03.2022 um 12:06 schrieb Jens Geyer:
> > > Java and the compiler (for C#)
> >
> >
> > Well, compiler code is a full package ... so that would then be a full
> > 0.16.1 indeed.
> >
> >
>
> --
>
> Randy Abernethy
> Managing Partner
> RX-M, LLCrandy.abernethy@rx-m.com
> o 415-800-2922
> c 415-624-6447
>
Re: Versions, patches and limited resources (was: Thoughts on a 0.9.4 rc)
Posted by Randy Abernethy <ra...@rx-m.com>.
If the community wants to move to 1.0 I would support that.
On Sat, Mar 5, 2022 at 3:11 AM Jens Geyer <je...@apache.org> wrote:
>
> Am 05.03.2022 um 12:06 schrieb Jens Geyer:
> > Java and the compiler (for C#)
>
>
> Well, compiler code is a full package ... so that would then be a full
> 0.16.1 indeed.
>
>
--
Randy Abernethy
Managing Partner
RX-M, LLCrandy.abernethy@rx-m.com
o 415-800-2922
c 415-624-6447
Re: Versions, patches and limited resources (was: Thoughts on a 0.9.4 rc)
Posted by Jens Geyer <je...@apache.org>.
Am 05.03.2022 um 12:06 schrieb Jens Geyer:
> Java and the compiler (for C#)
Well, compiler code is a full package ... so that would then be a full
0.16.1 indeed.
Versions, patches and limited resources (was: Thoughts on a 0.9.4 rc)
Posted by Jens Geyer <je...@apache.org>.
Hi,
we have received all in one week
* a request to release an updated 0.9.1 (!)
* a request to release 0.15.1 for one minor Java change
* a request to release 0.16.1 for one minor compiler code change
That raises two questions:
a) again if we should continue with 0.x as before or if it may be
time to switch to 1.x
b) how is it supposed to work out in the first place.
It's not that I don't want to provide the patches, and to me its a good
sign that there is obviously enough people out therw who like what we
are doing here. But like everyone elses my time is limited as well. And
I have a strong feeling that once we open that door, we come to weekly
releases very soon, which would then be a fulltime job.
Bottom line: Everybody wants an update, but nobody wants to do it -
understandable, because the whole process is time consuming.
What we could do to fix the urgent needs, except for 0.9.1 provide only
those packages that was asked for, i.e Java and the compiler (for C#).
But again, the current approach does not scale.
JensG
Am 09.01.2016 um 22:12 schrieb Jens Geyer:
> Hi,
>
> In general, I'm a proponent of more frequent releases. We had some
> mails last year and the consensus that I remember was to have
> something around 3 or 4 releases per year would be the optimum
> (correct me if I'm wrong).
>
> How we number them ... well, as a matter of fact, Thrift is already
> widely used in production. The languages on the market and their
> capabilities are constantly changing and will continue to do so, and
> so is Thrift, because of it's very nature of being a
> connectivity-enabling framework. So more than with most other
> software, there will never be /the/ one, 100% complete and 100% final
> Thrift version, because things change and Thrift needs to be
> constantly adapted.
>
> Version numbers around 1.0 are more a kind of a psychological thing:
> Below 1.0, the project devs have more freedom with what they do,
> because "the product is not final". So you kinda fly under the radar.
> This changes with >= 1.0 and after. People are now looking more
> closely, but they also take the whole thing more seriously, because
> obviously someone considered it being "ready to market".
>
> Last not least, I personally have no strong opinions about the
> numbering scheme (anymore), so whatever decision we come up with, I'm
> fine with either one.
>
> @Aki: The original plans were to release 1.0 after 0.9.3. I added the
> 0.9.4 tag to JIRA, and that's how all of a sudden the plan started to
> change ... ;-)
>
> Have fun,
> JensG
>
>
>
> -----Ursprüngliche Nachricht----- From: Aki Sukegawa
> Sent: Saturday, January 9, 2016 7:48 PM
> To: dev@thrift.apache.org ; jfarrell@apache.org
> Subject: Re: Thoughts on a 0.9.4 rc
>
> Great to hear that !
> I have a few local WIP that would be valuable for the release but I
> think I
> can make it very soon.
>
> One thing I want to propose is to use a different versioning scheme,
> something like 0.10.0.
>
> Last time, I saw users complaining like "Why such a change for *patch*
> release ??"
> And this time we have quite a few behavior changes like wire-format for
> certain language+protocols or default generator flags for a language.
> So 0.9.4 would induce wrong expectation among users.
>
> I understand the original intention of 0.9.x series and glad we're almost
> finishing this.
> But if a different scheme communicates the release content better,
> isn't it
> worth compromising last a few release numbers before 1.0 ?
>
>
> On Sun, Jan 10, 2016 at 2:46 AM Jake Farrell <jf...@apache.org> wrote:
>
>> What does everyone think about cutting a 0.9.4 release candidate in the
>> next week or so?
>>
>> -Jake
>>
>
Re: Thoughts on a 0.9.4 rc
Posted by Aki Sukegawa <ns...@apache.org>.
> the concept of a public "API" for Thrift is multifaceted
Indeed. I would categorize them by type of usages:
1. RPC users: use/implement generated service
2. serialization users: use generated struct (e.g. with Kafka)
3. advanced serialization users: directly call protocol write/readXxx (e.g.
projects like Parquet or scrooge)
> if change in the PHP lib mandates rolling over the version number
It seems unavoidable.
Alternatives like version-per-language+layer is complicated in practice.
Another point to consider is cross version compatibility breaks for
minor/patch releases:
A. cross version generated code and library
B. cross version client and server
IMO A. is safely allowed but B. is a major version bump.
Because normally A. only needs rebuild on a single host but B. needs
coordinated upgrade across multiple hosts.
Allowing B thus means that any version expression like "~X.X.X" or "^X.X.X"
is dangerous and should not be used for Thrift.
For me, the minimum scope of public API compat is 1 and B above.
2 and maybe 3 for Java only seems reasonable too.
Concretely, largely quoting BCG,
## 1
* IDL file format
* the CLI (compiler flags)
* the common means of instantiating servers and clients in the various
language libs
(including setStringLengthLimit, setCertPath etc)
* generated service interface
* communication behaviors (on timeout, unknown handler exception etc)
## B
* wire format
## 2
* generated struct methods
* TMemoryBuffer methods (or Transport read/write in general ?)
## 3
* (the semantics of the read* and write* methods)
On Wed, Jan 13, 2016 at 12:19 PM BCG <bg...@hushmail.com> wrote:
> On 01/12/2016 05:09 AM, Aki Sukegawa wrote:
> > Speaking about versioning, semver mandates us a defined set of public API
> > that is covered by it.
> > As I don't think we can document every individual API, we need a set of
> > rules that can decide what belongs to public API.
> > For example, Protocol.readFieldEnd, is it public API ?
> >
> >
> This seems like a shortcoming of "semver" for something like Thrift...
> in my mind the concept of a public "API" for Thrift is multifaceted (are
> we talking about the semantics of serializing/deserializing, the IDL
> file format, the CLI for compiler, etc). I'm not saying that "semver"
> is bad or anything just that it may not easily align with all projects.
>
> The situation is further complicated by the fact that each language lib
> has its own "API"... so, for instance, some if change in the PHP lib
> mandates rolling over the version number then that could have adverse
> effects in other languages' package managers that base defaults off of
> "semver" versioning (please correct me if I'm wrong about this... I'm
> not too familiar with those tools I'm just basing my statement off of
> what I've seen posted on this list). I'm not sure how to solve that...
> seems like it might be difficult to make everyone happy in that regard.
>
> In any case, in my mind the "public API" should at least include the IDL
> file format, the CLI, and the semantics of the read* and write* methods,
> and the common means of instantiating servers and clients in the various
> language libs.
>
>
>
>
Re: Thoughts on a 0.9.4 rc
Posted by BCG <bg...@hushmail.com>.
On 01/12/2016 05:09 AM, Aki Sukegawa wrote:
> Speaking about versioning, semver mandates us a defined set of public API
> that is covered by it.
> As I don't think we can document every individual API, we need a set of
> rules that can decide what belongs to public API.
> For example, Protocol.readFieldEnd, is it public API ?
>
>
This seems like a shortcoming of "semver" for something like Thrift...
in my mind the concept of a public "API" for Thrift is multifaceted (are
we talking about the semantics of serializing/deserializing, the IDL
file format, the CLI for compiler, etc). I'm not saying that "semver"
is bad or anything just that it may not easily align with all projects.
The situation is further complicated by the fact that each language lib
has its own "API"... so, for instance, some if change in the PHP lib
mandates rolling over the version number then that could have adverse
effects in other languages' package managers that base defaults off of
"semver" versioning (please correct me if I'm wrong about this... I'm
not too familiar with those tools I'm just basing my statement off of
what I've seen posted on this list). I'm not sure how to solve that...
seems like it might be difficult to make everyone happy in that regard.
In any case, in my mind the "public API" should at least include the IDL
file format, the CLI, and the semantics of the read* and write* methods,
and the common means of instantiating servers and clients in the various
language libs.
Re: Thoughts on a 0.9.4 rc
Posted by Aki Sukegawa <ns...@apache.org>.
In my observation, projects with semver tend to be forced to bump major
versions rather frequently.
So something like CMake in 2.0 or C++11 in 3.0 is not a big deal, because
it's not likely we have long standing 1.x anyway.
That said, I'm not particularly against any 1.0 plan and 0.10.0 would be
nice if 1.0 is controversial.
Speaking about versioning, semver mandates us a defined set of public API
that is covered by it.
As I don't think we can document every individual API, we need a set of
rules that can decide what belongs to public API.
For example, Protocol.readFieldEnd, is it public API ?
On Tue, Jan 12, 2016 at 8:08 AM Jens Geyer <je...@hotmail.com> wrote:
> Hi *,
>
> > In this regard, 1.0.0 might be nicer because automatic pull is overtly
> > inappropriate for this release IMO, at least for python and node.
>
> But that's what I'm saying: There will NEVER be a right time. You will hear
> that same sentence next time, only with slightly different content.
>
> Have fun,
> JensG
>
> PS: Thanks for all the work done in the last weeks, Aki. Highly
> appreciated!
>
>
>
> -----Ursprüngliche Nachricht-----
> From: Aki Sukegawa
> Sent: Monday, January 11, 2016 3:17 AM
> To: dev@thrift.apache.org
> Subject: Re: Thoughts on a 0.9.4 rc
>
> conventional_changelog seems to have a lot of over-wrap with current JIRA
> based one.
> What is pros and cons of this ? Obvious ones are:
> pros:
> * lightweight
> cons:
> * handling typo, wrong/forgotten tags etc is tricky
>
> The version number might not matter that much to poeple but maybe it does
> more to tools.
> npm et al. are more likely to be configured to automatically pull
> patch/minor version bumps.
> In this regard, 1.0.0 might be nicer because automatic pull is overtly
> inappropriate for this release IMO, at least for python and node.
>
> On Sun, Jan 10, 2016 at 7:43 PM Roger Meier <ro...@bufferoverflow.ch>
> wrote:
>
> > Hi
> >
> > fully agree on more frequent releases and I personally do not care
> > that much about the numbers. The cross testing is much more important.
> >
> > 0.10.0 why not or 0.9.4 if it is easier or a 1.0.0 it does not matter.
> >
> > The difficult thing is how do people really know what's changed and
> > that's why I like to bring in the conventional changelog discussion
> again.
> > Latest *git log --pretty=full* would look like this example:
> >
> > ---
> > fix(javascript): Dots in file names of includes causes dots in variable
> > names
> > Author: Kapil Joshi
> > Commit: Jens Geyer <je...@apache.org>
> >
> > based on the equivalent C# version
> >
> > This closes THRIFT-3314
> > ---
> > feat(python): Add package_prefix to python generator
> > Author: Eric Klaus <er...@workiva.com>
> > Commit: Jens Geyer <je...@apache.org>
> >
> > This closes THRIFT-3499
> > This closes #755
> > ---
> > fix(dart): TSocket onError stream should be typed as Object
> > Author: Mark Erickson <ma...@workiva.com>
> > Commit: Jens Geyer <je...@apache.org>
> >
> > This closes THRIFT-3520
> > This closes #770
> > ---
> > feat(php): Add PHP 7 version of php_thrift_protocol
> > Author: David Soria Parra <ds...@php.net>
> > Commit: Roger Meier <ro...@apache.org>
> >
> > This is an initial port of php_thrift_protocol to PHP7. However as
> > we deal with zval's all over the place, we opt for separating
> > the C files completely leading to some overhead. However this
> > is a good start to see the differences in the implementation. From
> > there we should follow up with a more unified approach by refactoring
> > parts of the zval handling to be more generic so we can plug it
> > into PHP 7 and PHP 5 extensions.
> >
> > Tested this by running with TestClient.php against a CPP server
> > and using TBinaryProtocolAccelerated.
> >
> > This closes THRIFT-3514
> > This closes #765
> > ---
> >
> > See [1] for a nice introduction on conventional changelog and a
> > generated CHANGELOG.md based on git commit data only.
> >
> > Cheers
> > roger
> >
> >
> > [1]
> >
> >
> http://notebook.aaronwest.net/2015/08/03/better-documentation-using-conventional-changelog.html
> >
> >
> > Quoting Jens Geyer <je...@hotmail.com>:
> >
> > > Hi,
> > >
> > > In general, I'm a proponent of more frequent releases. We had some
> > > mails last year and the consensus that I remember was to have
> > > something around 3 or 4 releases per year would be the optimum
> > > (correct me if I'm wrong).
> > >
> > > How we number them ... well, as a matter of fact, Thrift is already
> > > widely used in production. The languages on the market and their
> > > capabilities are constantly changing and will continue to do so, and
> > > so is Thrift, because of it's very nature of being a
> > > connectivity-enabling framework. So more than with most other
> > > software, there will never be /the/ one, 100% complete and 100%
> > > final Thrift version, because things change and Thrift needs to be
> > > constantly adapted.
> > >
> > > Version numbers around 1.0 are more a kind of a psychological thing:
> > > Below 1.0, the project devs have more freedom with what they do,
> > > because "the product is not final". So you kinda fly under the
> > > radar. This changes with >= 1.0 and after. People are now looking
> > > more closely, but they also take the whole thing more seriously,
> > > because obviously someone considered it being "ready to market".
> > >
> > > Last not least, I personally have no strong opinions about the
> > > numbering scheme (anymore), so whatever decision we come up with,
> > > I'm fine with either one.
> > >
> > > @Aki: The original plans were to release 1.0 after 0.9.3. I added
> > > the 0.9.4 tag to JIRA, and that's how all of a sudden the plan
> > > started to change ... ;-)
> > >
> > > Have fun,
> > > JensG
> > >
> > >
> > >
> > > -----Ursprüngliche Nachricht----- From: Aki Sukegawa
> > > Sent: Saturday, January 9, 2016 7:48 PM
> > > To: dev@thrift.apache.org ; jfarrell@apache.org
> > > Subject: Re: Thoughts on a 0.9.4 rc
> > >
> > > Great to hear that !
> > > I have a few local WIP that would be valuable for the release but I
> > think I
> > > can make it very soon.
> > >
> > > One thing I want to propose is to use a different versioning scheme,
> > > something like 0.10.0.
> > >
> > > Last time, I saw users complaining like "Why such a change for *patch*
> > > release ??"
> > > And this time we have quite a few behavior changes like wire-format for
> > > certain language+protocols or default generator flags for a language.
> > > So 0.9.4 would induce wrong expectation among users.
> > >
> > > I understand the original intention of 0.9.x series and glad we're
> > > almost
> > > finishing this.
> > > But if a different scheme communicates the release content better,
> isn't
> > it
> > > worth compromising last a few release numbers before 1.0 ?
> > >
> > >
> > > On Sun, Jan 10, 2016 at 2:46 AM Jake Farrell <jf...@apache.org>
> > wrote:
> > >
> > >> What does everyone think about cutting a 0.9.4 release candidate in
> the
> > >> next week or so?
> > >>
> > >> -Jake
> > >>
> >
> >
> >
>
>
Re: Thoughts on a 0.9.4 rc
Posted by Jens Geyer <je...@hotmail.com>.
Hi *,
> In this regard, 1.0.0 might be nicer because automatic pull is overtly
> inappropriate for this release IMO, at least for python and node.
But that's what I'm saying: There will NEVER be a right time. You will hear
that same sentence next time, only with slightly different content.
Have fun,
JensG
PS: Thanks for all the work done in the last weeks, Aki. Highly appreciated!
-----Ursprüngliche Nachricht-----
From: Aki Sukegawa
Sent: Monday, January 11, 2016 3:17 AM
To: dev@thrift.apache.org
Subject: Re: Thoughts on a 0.9.4 rc
conventional_changelog seems to have a lot of over-wrap with current JIRA
based one.
What is pros and cons of this ? Obvious ones are:
pros:
* lightweight
cons:
* handling typo, wrong/forgotten tags etc is tricky
The version number might not matter that much to poeple but maybe it does
more to tools.
npm et al. are more likely to be configured to automatically pull
patch/minor version bumps.
In this regard, 1.0.0 might be nicer because automatic pull is overtly
inappropriate for this release IMO, at least for python and node.
On Sun, Jan 10, 2016 at 7:43 PM Roger Meier <ro...@bufferoverflow.ch> wrote:
> Hi
>
> fully agree on more frequent releases and I personally do not care
> that much about the numbers. The cross testing is much more important.
>
> 0.10.0 why not or 0.9.4 if it is easier or a 1.0.0 it does not matter.
>
> The difficult thing is how do people really know what's changed and
> that's why I like to bring in the conventional changelog discussion again.
> Latest *git log --pretty=full* would look like this example:
>
> ---
> fix(javascript): Dots in file names of includes causes dots in variable
> names
> Author: Kapil Joshi
> Commit: Jens Geyer <je...@apache.org>
>
> based on the equivalent C# version
>
> This closes THRIFT-3314
> ---
> feat(python): Add package_prefix to python generator
> Author: Eric Klaus <er...@workiva.com>
> Commit: Jens Geyer <je...@apache.org>
>
> This closes THRIFT-3499
> This closes #755
> ---
> fix(dart): TSocket onError stream should be typed as Object
> Author: Mark Erickson <ma...@workiva.com>
> Commit: Jens Geyer <je...@apache.org>
>
> This closes THRIFT-3520
> This closes #770
> ---
> feat(php): Add PHP 7 version of php_thrift_protocol
> Author: David Soria Parra <ds...@php.net>
> Commit: Roger Meier <ro...@apache.org>
>
> This is an initial port of php_thrift_protocol to PHP7. However as
> we deal with zval's all over the place, we opt for separating
> the C files completely leading to some overhead. However this
> is a good start to see the differences in the implementation. From
> there we should follow up with a more unified approach by refactoring
> parts of the zval handling to be more generic so we can plug it
> into PHP 7 and PHP 5 extensions.
>
> Tested this by running with TestClient.php against a CPP server
> and using TBinaryProtocolAccelerated.
>
> This closes THRIFT-3514
> This closes #765
> ---
>
> See [1] for a nice introduction on conventional changelog and a
> generated CHANGELOG.md based on git commit data only.
>
> Cheers
> roger
>
>
> [1]
>
> http://notebook.aaronwest.net/2015/08/03/better-documentation-using-conventional-changelog.html
>
>
> Quoting Jens Geyer <je...@hotmail.com>:
>
> > Hi,
> >
> > In general, I'm a proponent of more frequent releases. We had some
> > mails last year and the consensus that I remember was to have
> > something around 3 or 4 releases per year would be the optimum
> > (correct me if I'm wrong).
> >
> > How we number them ... well, as a matter of fact, Thrift is already
> > widely used in production. The languages on the market and their
> > capabilities are constantly changing and will continue to do so, and
> > so is Thrift, because of it's very nature of being a
> > connectivity-enabling framework. So more than with most other
> > software, there will never be /the/ one, 100% complete and 100%
> > final Thrift version, because things change and Thrift needs to be
> > constantly adapted.
> >
> > Version numbers around 1.0 are more a kind of a psychological thing:
> > Below 1.0, the project devs have more freedom with what they do,
> > because "the product is not final". So you kinda fly under the
> > radar. This changes with >= 1.0 and after. People are now looking
> > more closely, but they also take the whole thing more seriously,
> > because obviously someone considered it being "ready to market".
> >
> > Last not least, I personally have no strong opinions about the
> > numbering scheme (anymore), so whatever decision we come up with,
> > I'm fine with either one.
> >
> > @Aki: The original plans were to release 1.0 after 0.9.3. I added
> > the 0.9.4 tag to JIRA, and that's how all of a sudden the plan
> > started to change ... ;-)
> >
> > Have fun,
> > JensG
> >
> >
> >
> > -----Ursprüngliche Nachricht----- From: Aki Sukegawa
> > Sent: Saturday, January 9, 2016 7:48 PM
> > To: dev@thrift.apache.org ; jfarrell@apache.org
> > Subject: Re: Thoughts on a 0.9.4 rc
> >
> > Great to hear that !
> > I have a few local WIP that would be valuable for the release but I
> think I
> > can make it very soon.
> >
> > One thing I want to propose is to use a different versioning scheme,
> > something like 0.10.0.
> >
> > Last time, I saw users complaining like "Why such a change for *patch*
> > release ??"
> > And this time we have quite a few behavior changes like wire-format for
> > certain language+protocols or default generator flags for a language.
> > So 0.9.4 would induce wrong expectation among users.
> >
> > I understand the original intention of 0.9.x series and glad we're
> > almost
> > finishing this.
> > But if a different scheme communicates the release content better, isn't
> it
> > worth compromising last a few release numbers before 1.0 ?
> >
> >
> > On Sun, Jan 10, 2016 at 2:46 AM Jake Farrell <jf...@apache.org>
> wrote:
> >
> >> What does everyone think about cutting a 0.9.4 release candidate in the
> >> next week or so?
> >>
> >> -Jake
> >>
>
>
>
Re: Thoughts on a 0.9.4 rc
Posted by Roger Meier <ro...@bufferoverflow.ch>.
Hi cross communicators!
Quoting Aki Sukegawa <ns...@apache.org>:
> conventional_changelog seems to have a lot of over-wrap with current JIRA
> based one.
yes, there is an overlap but we have it already, also with GitHub.
> What is pros and cons of this ? Obvious ones are:
> pros:
> * lightweight
* based on git data only
* directly see if a commit is a feature, fix, style change, etc.
* become able to generate a useful CHANGELOG.md out from the git repo
(issue trackers might change, but git history and commit messages stay)
* many projects are using it, especially in the web, node.js area, e.g.
* Mozilla Accounts(fxa-xy)
* angular.js
* We use it internally on a platform and made very good experiences
> cons:
> * handling typo, wrong/forgotten tags etc is tricky
* people need to understand and follow the rules
however, it depends on a proper description such as this one:
https://github.com/fossology/fossology/blob/master/CONTRIBUTING.md#git-commit-conventions
>
> The version number might not matter that much to poeple but maybe it does
> more to tools.
> npm et al. are more likely to be configured to automatically pull
> patch/minor version bumps.
> In this regard, 1.0.0 might be nicer because automatic pull is overtly
> inappropriate for this release IMO, at least for python and node.
yes, I agree we should go for 1.0.0 as we have decided some months ago.
Happy coding!
-roger
>
> On Sun, Jan 10, 2016 at 7:43 PM Roger Meier <ro...@bufferoverflow.ch> wrote:
>
>> Hi
>>
>> fully agree on more frequent releases and I personally do not care
>> that much about the numbers. The cross testing is much more important.
>>
>> 0.10.0 why not or 0.9.4 if it is easier or a 1.0.0 it does not matter.
>>
>> The difficult thing is how do people really know what's changed and
>> that's why I like to bring in the conventional changelog discussion again.
>> Latest *git log --pretty=full* would look like this example:
>>
>> ---
>> fix(javascript): Dots in file names of includes causes dots in variable
>> names
>> Author: Kapil Joshi
>> Commit: Jens Geyer <je...@apache.org>
>>
>> based on the equivalent C# version
>>
>> This closes THRIFT-3314
>> ---
>> feat(python): Add package_prefix to python generator
>> Author: Eric Klaus <er...@workiva.com>
>> Commit: Jens Geyer <je...@apache.org>
>>
>> This closes THRIFT-3499
>> This closes #755
>> ---
>> fix(dart): TSocket onError stream should be typed as Object
>> Author: Mark Erickson <ma...@workiva.com>
>> Commit: Jens Geyer <je...@apache.org>
>>
>> This closes THRIFT-3520
>> This closes #770
>> ---
>> feat(php): Add PHP 7 version of php_thrift_protocol
>> Author: David Soria Parra <ds...@php.net>
>> Commit: Roger Meier <ro...@apache.org>
>>
>> This is an initial port of php_thrift_protocol to PHP7. However as
>> we deal with zval's all over the place, we opt for separating
>> the C files completely leading to some overhead. However this
>> is a good start to see the differences in the implementation. From
>> there we should follow up with a more unified approach by refactoring
>> parts of the zval handling to be more generic so we can plug it
>> into PHP 7 and PHP 5 extensions.
>>
>> Tested this by running with TestClient.php against a CPP server
>> and using TBinaryProtocolAccelerated.
>>
>> This closes THRIFT-3514
>> This closes #765
>> ---
>>
>> See [1] for a nice introduction on conventional changelog and a
>> generated CHANGELOG.md based on git commit data only.
>>
>> Cheers
>> roger
>>
>>
>> [1]
>>
>> http://notebook.aaronwest.net/2015/08/03/better-documentation-using-conventional-changelog.html
>>
>>
>> Quoting Jens Geyer <je...@hotmail.com>:
>>
>> > Hi,
>> >
>> > In general, I'm a proponent of more frequent releases. We had some
>> > mails last year and the consensus that I remember was to have
>> > something around 3 or 4 releases per year would be the optimum
>> > (correct me if I'm wrong).
>> >
>> > How we number them ... well, as a matter of fact, Thrift is already
>> > widely used in production. The languages on the market and their
>> > capabilities are constantly changing and will continue to do so, and
>> > so is Thrift, because of it's very nature of being a
>> > connectivity-enabling framework. So more than with most other
>> > software, there will never be /the/ one, 100% complete and 100%
>> > final Thrift version, because things change and Thrift needs to be
>> > constantly adapted.
>> >
>> > Version numbers around 1.0 are more a kind of a psychological thing:
>> > Below 1.0, the project devs have more freedom with what they do,
>> > because "the product is not final". So you kinda fly under the
>> > radar. This changes with >= 1.0 and after. People are now looking
>> > more closely, but they also take the whole thing more seriously,
>> > because obviously someone considered it being "ready to market".
>> >
>> > Last not least, I personally have no strong opinions about the
>> > numbering scheme (anymore), so whatever decision we come up with,
>> > I'm fine with either one.
>> >
>> > @Aki: The original plans were to release 1.0 after 0.9.3. I added
>> > the 0.9.4 tag to JIRA, and that's how all of a sudden the plan
>> > started to change ... ;-)
>> >
>> > Have fun,
>> > JensG
>> >
>> >
>> >
>> > -----Ursprüngliche Nachricht----- From: Aki Sukegawa
>> > Sent: Saturday, January 9, 2016 7:48 PM
>> > To: dev@thrift.apache.org ; jfarrell@apache.org
>> > Subject: Re: Thoughts on a 0.9.4 rc
>> >
>> > Great to hear that !
>> > I have a few local WIP that would be valuable for the release but I
>> think I
>> > can make it very soon.
>> >
>> > One thing I want to propose is to use a different versioning scheme,
>> > something like 0.10.0.
>> >
>> > Last time, I saw users complaining like "Why such a change for *patch*
>> > release ??"
>> > And this time we have quite a few behavior changes like wire-format for
>> > certain language+protocols or default generator flags for a language.
>> > So 0.9.4 would induce wrong expectation among users.
>> >
>> > I understand the original intention of 0.9.x series and glad we're almost
>> > finishing this.
>> > But if a different scheme communicates the release content better, isn't
>> it
>> > worth compromising last a few release numbers before 1.0 ?
>> >
>> >
>> > On Sun, Jan 10, 2016 at 2:46 AM Jake Farrell <jf...@apache.org>
>> wrote:
>> >
>> >> What does everyone think about cutting a 0.9.4 release candidate in the
>> >> next week or so?
>> >>
>> >> -Jake
>> >>
>>
>>
>>
Re: Thoughts on a 0.9.4 rc
Posted by Roger Meier <ro...@bufferoverflow.ch>.
Thanks Randy!
To be honest I see it the other way around;-)
1. C++11 (replace boost with std, etc.)
2. Python 3 (Is already in place)
3. CMake (more to do, but autoconf is still available)
happy coding!
roger
Quoting Randy Abernethy <ra...@gmail.com>:
> To me 1.0 means (in order of significance):
>
> 1. Build is fully cmake (no bootstrap.sh, etc.)
> 2. Python 3 supported
> 3. Modern C++ supported
>
> That is of course just my wish list. The first one is the most significant
> given it impacts all users.
>
> On Sun, Jan 10, 2016 at 6:17 PM, Aki Sukegawa <ns...@apache.org> wrote:
>
>> conventional_changelog seems to have a lot of over-wrap with current JIRA
>> based one.
>> What is pros and cons of this ? Obvious ones are:
>> pros:
>> * lightweight
>> cons:
>> * handling typo, wrong/forgotten tags etc is tricky
>>
>> The version number might not matter that much to poeple but maybe it does
>> more to tools.
>> npm et al. are more likely to be configured to automatically pull
>> patch/minor version bumps.
>> In this regard, 1.0.0 might be nicer because automatic pull is overtly
>> inappropriate for this release IMO, at least for python and node.
>>
>> On Sun, Jan 10, 2016 at 7:43 PM Roger Meier <ro...@bufferoverflow.ch>
>> wrote:
>>
>> > Hi
>> >
>> > fully agree on more frequent releases and I personally do not care
>> > that much about the numbers. The cross testing is much more important.
>> >
>> > 0.10.0 why not or 0.9.4 if it is easier or a 1.0.0 it does not matter.
>> >
>> > The difficult thing is how do people really know what's changed and
>> > that's why I like to bring in the conventional changelog discussion
>> again.
>> > Latest *git log --pretty=full* would look like this example:
>> >
>> > ---
>> > fix(javascript): Dots in file names of includes causes dots in variable
>> > names
>> > Author: Kapil Joshi
>> > Commit: Jens Geyer <je...@apache.org>
>> >
>> > based on the equivalent C# version
>> >
>> > This closes THRIFT-3314
>> > ---
>> > feat(python): Add package_prefix to python generator
>> > Author: Eric Klaus <er...@workiva.com>
>> > Commit: Jens Geyer <je...@apache.org>
>> >
>> > This closes THRIFT-3499
>> > This closes #755
>> > ---
>> > fix(dart): TSocket onError stream should be typed as Object
>> > Author: Mark Erickson <ma...@workiva.com>
>> > Commit: Jens Geyer <je...@apache.org>
>> >
>> > This closes THRIFT-3520
>> > This closes #770
>> > ---
>> > feat(php): Add PHP 7 version of php_thrift_protocol
>> > Author: David Soria Parra <ds...@php.net>
>> > Commit: Roger Meier <ro...@apache.org>
>> >
>> > This is an initial port of php_thrift_protocol to PHP7. However as
>> > we deal with zval's all over the place, we opt for separating
>> > the C files completely leading to some overhead. However this
>> > is a good start to see the differences in the implementation. From
>> > there we should follow up with a more unified approach by refactoring
>> > parts of the zval handling to be more generic so we can plug it
>> > into PHP 7 and PHP 5 extensions.
>> >
>> > Tested this by running with TestClient.php against a CPP server
>> > and using TBinaryProtocolAccelerated.
>> >
>> > This closes THRIFT-3514
>> > This closes #765
>> > ---
>> >
>> > See [1] for a nice introduction on conventional changelog and a
>> > generated CHANGELOG.md based on git commit data only.
>> >
>> > Cheers
>> > roger
>> >
>> >
>> > [1]
>> >
>> >
>> http://notebook.aaronwest.net/2015/08/03/better-documentation-using-conventional-changelog.html
>> >
>> >
>> > Quoting Jens Geyer <je...@hotmail.com>:
>> >
>> > > Hi,
>> > >
>> > > In general, I'm a proponent of more frequent releases. We had some
>> > > mails last year and the consensus that I remember was to have
>> > > something around 3 or 4 releases per year would be the optimum
>> > > (correct me if I'm wrong).
>> > >
>> > > How we number them ... well, as a matter of fact, Thrift is already
>> > > widely used in production. The languages on the market and their
>> > > capabilities are constantly changing and will continue to do so, and
>> > > so is Thrift, because of it's very nature of being a
>> > > connectivity-enabling framework. So more than with most other
>> > > software, there will never be /the/ one, 100% complete and 100%
>> > > final Thrift version, because things change and Thrift needs to be
>> > > constantly adapted.
>> > >
>> > > Version numbers around 1.0 are more a kind of a psychological thing:
>> > > Below 1.0, the project devs have more freedom with what they do,
>> > > because "the product is not final". So you kinda fly under the
>> > > radar. This changes with >= 1.0 and after. People are now looking
>> > > more closely, but they also take the whole thing more seriously,
>> > > because obviously someone considered it being "ready to market".
>> > >
>> > > Last not least, I personally have no strong opinions about the
>> > > numbering scheme (anymore), so whatever decision we come up with,
>> > > I'm fine with either one.
>> > >
>> > > @Aki: The original plans were to release 1.0 after 0.9.3. I added
>> > > the 0.9.4 tag to JIRA, and that's how all of a sudden the plan
>> > > started to change ... ;-)
>> > >
>> > > Have fun,
>> > > JensG
>> > >
>> > >
>> > >
>> > > -----Ursprüngliche Nachricht----- From: Aki Sukegawa
>> > > Sent: Saturday, January 9, 2016 7:48 PM
>> > > To: dev@thrift.apache.org ; jfarrell@apache.org
>> > > Subject: Re: Thoughts on a 0.9.4 rc
>> > >
>> > > Great to hear that !
>> > > I have a few local WIP that would be valuable for the release but I
>> > think I
>> > > can make it very soon.
>> > >
>> > > One thing I want to propose is to use a different versioning scheme,
>> > > something like 0.10.0.
>> > >
>> > > Last time, I saw users complaining like "Why such a change for *patch*
>> > > release ??"
>> > > And this time we have quite a few behavior changes like wire-format for
>> > > certain language+protocols or default generator flags for a language.
>> > > So 0.9.4 would induce wrong expectation among users.
>> > >
>> > > I understand the original intention of 0.9.x series and glad we're
>> almost
>> > > finishing this.
>> > > But if a different scheme communicates the release content better,
>> isn't
>> > it
>> > > worth compromising last a few release numbers before 1.0 ?
>> > >
>> > >
>> > > On Sun, Jan 10, 2016 at 2:46 AM Jake Farrell <jf...@apache.org>
>> > wrote:
>> > >
>> > >> What does everyone think about cutting a 0.9.4 release candidate in
>> the
>> > >> next week or so?
>> > >>
>> > >> -Jake
>> > >>
>> >
>> >
>> >
>>
Re: Thoughts on a 0.9.4 rc
Posted by Randy Abernethy <ra...@gmail.com>.
To me 1.0 means (in order of significance):
1. Build is fully cmake (no bootstrap.sh, etc.)
2. Python 3 supported
3. Modern C++ supported
That is of course just my wish list. The first one is the most significant
given it impacts all users.
On Sun, Jan 10, 2016 at 6:17 PM, Aki Sukegawa <ns...@apache.org> wrote:
> conventional_changelog seems to have a lot of over-wrap with current JIRA
> based one.
> What is pros and cons of this ? Obvious ones are:
> pros:
> * lightweight
> cons:
> * handling typo, wrong/forgotten tags etc is tricky
>
> The version number might not matter that much to poeple but maybe it does
> more to tools.
> npm et al. are more likely to be configured to automatically pull
> patch/minor version bumps.
> In this regard, 1.0.0 might be nicer because automatic pull is overtly
> inappropriate for this release IMO, at least for python and node.
>
> On Sun, Jan 10, 2016 at 7:43 PM Roger Meier <ro...@bufferoverflow.ch>
> wrote:
>
> > Hi
> >
> > fully agree on more frequent releases and I personally do not care
> > that much about the numbers. The cross testing is much more important.
> >
> > 0.10.0 why not or 0.9.4 if it is easier or a 1.0.0 it does not matter.
> >
> > The difficult thing is how do people really know what's changed and
> > that's why I like to bring in the conventional changelog discussion
> again.
> > Latest *git log --pretty=full* would look like this example:
> >
> > ---
> > fix(javascript): Dots in file names of includes causes dots in variable
> > names
> > Author: Kapil Joshi
> > Commit: Jens Geyer <je...@apache.org>
> >
> > based on the equivalent C# version
> >
> > This closes THRIFT-3314
> > ---
> > feat(python): Add package_prefix to python generator
> > Author: Eric Klaus <er...@workiva.com>
> > Commit: Jens Geyer <je...@apache.org>
> >
> > This closes THRIFT-3499
> > This closes #755
> > ---
> > fix(dart): TSocket onError stream should be typed as Object
> > Author: Mark Erickson <ma...@workiva.com>
> > Commit: Jens Geyer <je...@apache.org>
> >
> > This closes THRIFT-3520
> > This closes #770
> > ---
> > feat(php): Add PHP 7 version of php_thrift_protocol
> > Author: David Soria Parra <ds...@php.net>
> > Commit: Roger Meier <ro...@apache.org>
> >
> > This is an initial port of php_thrift_protocol to PHP7. However as
> > we deal with zval's all over the place, we opt for separating
> > the C files completely leading to some overhead. However this
> > is a good start to see the differences in the implementation. From
> > there we should follow up with a more unified approach by refactoring
> > parts of the zval handling to be more generic so we can plug it
> > into PHP 7 and PHP 5 extensions.
> >
> > Tested this by running with TestClient.php against a CPP server
> > and using TBinaryProtocolAccelerated.
> >
> > This closes THRIFT-3514
> > This closes #765
> > ---
> >
> > See [1] for a nice introduction on conventional changelog and a
> > generated CHANGELOG.md based on git commit data only.
> >
> > Cheers
> > roger
> >
> >
> > [1]
> >
> >
> http://notebook.aaronwest.net/2015/08/03/better-documentation-using-conventional-changelog.html
> >
> >
> > Quoting Jens Geyer <je...@hotmail.com>:
> >
> > > Hi,
> > >
> > > In general, I'm a proponent of more frequent releases. We had some
> > > mails last year and the consensus that I remember was to have
> > > something around 3 or 4 releases per year would be the optimum
> > > (correct me if I'm wrong).
> > >
> > > How we number them ... well, as a matter of fact, Thrift is already
> > > widely used in production. The languages on the market and their
> > > capabilities are constantly changing and will continue to do so, and
> > > so is Thrift, because of it's very nature of being a
> > > connectivity-enabling framework. So more than with most other
> > > software, there will never be /the/ one, 100% complete and 100%
> > > final Thrift version, because things change and Thrift needs to be
> > > constantly adapted.
> > >
> > > Version numbers around 1.0 are more a kind of a psychological thing:
> > > Below 1.0, the project devs have more freedom with what they do,
> > > because "the product is not final". So you kinda fly under the
> > > radar. This changes with >= 1.0 and after. People are now looking
> > > more closely, but they also take the whole thing more seriously,
> > > because obviously someone considered it being "ready to market".
> > >
> > > Last not least, I personally have no strong opinions about the
> > > numbering scheme (anymore), so whatever decision we come up with,
> > > I'm fine with either one.
> > >
> > > @Aki: The original plans were to release 1.0 after 0.9.3. I added
> > > the 0.9.4 tag to JIRA, and that's how all of a sudden the plan
> > > started to change ... ;-)
> > >
> > > Have fun,
> > > JensG
> > >
> > >
> > >
> > > -----Ursprüngliche Nachricht----- From: Aki Sukegawa
> > > Sent: Saturday, January 9, 2016 7:48 PM
> > > To: dev@thrift.apache.org ; jfarrell@apache.org
> > > Subject: Re: Thoughts on a 0.9.4 rc
> > >
> > > Great to hear that !
> > > I have a few local WIP that would be valuable for the release but I
> > think I
> > > can make it very soon.
> > >
> > > One thing I want to propose is to use a different versioning scheme,
> > > something like 0.10.0.
> > >
> > > Last time, I saw users complaining like "Why such a change for *patch*
> > > release ??"
> > > And this time we have quite a few behavior changes like wire-format for
> > > certain language+protocols or default generator flags for a language.
> > > So 0.9.4 would induce wrong expectation among users.
> > >
> > > I understand the original intention of 0.9.x series and glad we're
> almost
> > > finishing this.
> > > But if a different scheme communicates the release content better,
> isn't
> > it
> > > worth compromising last a few release numbers before 1.0 ?
> > >
> > >
> > > On Sun, Jan 10, 2016 at 2:46 AM Jake Farrell <jf...@apache.org>
> > wrote:
> > >
> > >> What does everyone think about cutting a 0.9.4 release candidate in
> the
> > >> next week or so?
> > >>
> > >> -Jake
> > >>
> >
> >
> >
>
Re: Thoughts on a 0.9.4 rc
Posted by Aki Sukegawa <ns...@apache.org>.
conventional_changelog seems to have a lot of over-wrap with current JIRA
based one.
What is pros and cons of this ? Obvious ones are:
pros:
* lightweight
cons:
* handling typo, wrong/forgotten tags etc is tricky
The version number might not matter that much to poeple but maybe it does
more to tools.
npm et al. are more likely to be configured to automatically pull
patch/minor version bumps.
In this regard, 1.0.0 might be nicer because automatic pull is overtly
inappropriate for this release IMO, at least for python and node.
On Sun, Jan 10, 2016 at 7:43 PM Roger Meier <ro...@bufferoverflow.ch> wrote:
> Hi
>
> fully agree on more frequent releases and I personally do not care
> that much about the numbers. The cross testing is much more important.
>
> 0.10.0 why not or 0.9.4 if it is easier or a 1.0.0 it does not matter.
>
> The difficult thing is how do people really know what's changed and
> that's why I like to bring in the conventional changelog discussion again.
> Latest *git log --pretty=full* would look like this example:
>
> ---
> fix(javascript): Dots in file names of includes causes dots in variable
> names
> Author: Kapil Joshi
> Commit: Jens Geyer <je...@apache.org>
>
> based on the equivalent C# version
>
> This closes THRIFT-3314
> ---
> feat(python): Add package_prefix to python generator
> Author: Eric Klaus <er...@workiva.com>
> Commit: Jens Geyer <je...@apache.org>
>
> This closes THRIFT-3499
> This closes #755
> ---
> fix(dart): TSocket onError stream should be typed as Object
> Author: Mark Erickson <ma...@workiva.com>
> Commit: Jens Geyer <je...@apache.org>
>
> This closes THRIFT-3520
> This closes #770
> ---
> feat(php): Add PHP 7 version of php_thrift_protocol
> Author: David Soria Parra <ds...@php.net>
> Commit: Roger Meier <ro...@apache.org>
>
> This is an initial port of php_thrift_protocol to PHP7. However as
> we deal with zval's all over the place, we opt for separating
> the C files completely leading to some overhead. However this
> is a good start to see the differences in the implementation. From
> there we should follow up with a more unified approach by refactoring
> parts of the zval handling to be more generic so we can plug it
> into PHP 7 and PHP 5 extensions.
>
> Tested this by running with TestClient.php against a CPP server
> and using TBinaryProtocolAccelerated.
>
> This closes THRIFT-3514
> This closes #765
> ---
>
> See [1] for a nice introduction on conventional changelog and a
> generated CHANGELOG.md based on git commit data only.
>
> Cheers
> roger
>
>
> [1]
>
> http://notebook.aaronwest.net/2015/08/03/better-documentation-using-conventional-changelog.html
>
>
> Quoting Jens Geyer <je...@hotmail.com>:
>
> > Hi,
> >
> > In general, I'm a proponent of more frequent releases. We had some
> > mails last year and the consensus that I remember was to have
> > something around 3 or 4 releases per year would be the optimum
> > (correct me if I'm wrong).
> >
> > How we number them ... well, as a matter of fact, Thrift is already
> > widely used in production. The languages on the market and their
> > capabilities are constantly changing and will continue to do so, and
> > so is Thrift, because of it's very nature of being a
> > connectivity-enabling framework. So more than with most other
> > software, there will never be /the/ one, 100% complete and 100%
> > final Thrift version, because things change and Thrift needs to be
> > constantly adapted.
> >
> > Version numbers around 1.0 are more a kind of a psychological thing:
> > Below 1.0, the project devs have more freedom with what they do,
> > because "the product is not final". So you kinda fly under the
> > radar. This changes with >= 1.0 and after. People are now looking
> > more closely, but they also take the whole thing more seriously,
> > because obviously someone considered it being "ready to market".
> >
> > Last not least, I personally have no strong opinions about the
> > numbering scheme (anymore), so whatever decision we come up with,
> > I'm fine with either one.
> >
> > @Aki: The original plans were to release 1.0 after 0.9.3. I added
> > the 0.9.4 tag to JIRA, and that's how all of a sudden the plan
> > started to change ... ;-)
> >
> > Have fun,
> > JensG
> >
> >
> >
> > -----Ursprüngliche Nachricht----- From: Aki Sukegawa
> > Sent: Saturday, January 9, 2016 7:48 PM
> > To: dev@thrift.apache.org ; jfarrell@apache.org
> > Subject: Re: Thoughts on a 0.9.4 rc
> >
> > Great to hear that !
> > I have a few local WIP that would be valuable for the release but I
> think I
> > can make it very soon.
> >
> > One thing I want to propose is to use a different versioning scheme,
> > something like 0.10.0.
> >
> > Last time, I saw users complaining like "Why such a change for *patch*
> > release ??"
> > And this time we have quite a few behavior changes like wire-format for
> > certain language+protocols or default generator flags for a language.
> > So 0.9.4 would induce wrong expectation among users.
> >
> > I understand the original intention of 0.9.x series and glad we're almost
> > finishing this.
> > But if a different scheme communicates the release content better, isn't
> it
> > worth compromising last a few release numbers before 1.0 ?
> >
> >
> > On Sun, Jan 10, 2016 at 2:46 AM Jake Farrell <jf...@apache.org>
> wrote:
> >
> >> What does everyone think about cutting a 0.9.4 release candidate in the
> >> next week or so?
> >>
> >> -Jake
> >>
>
>
>
Re: Thoughts on a 0.9.4 rc
Posted by Roger Meier <ro...@bufferoverflow.ch>.
Hi
fully agree on more frequent releases and I personally do not care
that much about the numbers. The cross testing is much more important.
0.10.0 why not or 0.9.4 if it is easier or a 1.0.0 it does not matter.
The difficult thing is how do people really know what's changed and
that's why I like to bring in the conventional changelog discussion again.
Latest *git log --pretty=full* would look like this example:
---
fix(javascript): Dots in file names of includes causes dots in variable names
Author: Kapil Joshi
Commit: Jens Geyer <je...@apache.org>
based on the equivalent C# version
This closes THRIFT-3314
---
feat(python): Add package_prefix to python generator
Author: Eric Klaus <er...@workiva.com>
Commit: Jens Geyer <je...@apache.org>
This closes THRIFT-3499
This closes #755
---
fix(dart): TSocket onError stream should be typed as Object
Author: Mark Erickson <ma...@workiva.com>
Commit: Jens Geyer <je...@apache.org>
This closes THRIFT-3520
This closes #770
---
feat(php): Add PHP 7 version of php_thrift_protocol
Author: David Soria Parra <ds...@php.net>
Commit: Roger Meier <ro...@apache.org>
This is an initial port of php_thrift_protocol to PHP7. However as
we deal with zval's all over the place, we opt for separating
the C files completely leading to some overhead. However this
is a good start to see the differences in the implementation. From
there we should follow up with a more unified approach by refactoring
parts of the zval handling to be more generic so we can plug it
into PHP 7 and PHP 5 extensions.
Tested this by running with TestClient.php against a CPP server
and using TBinaryProtocolAccelerated.
This closes THRIFT-3514
This closes #765
---
See [1] for a nice introduction on conventional changelog and a
generated CHANGELOG.md based on git commit data only.
Cheers
roger
[1]
http://notebook.aaronwest.net/2015/08/03/better-documentation-using-conventional-changelog.html
Quoting Jens Geyer <je...@hotmail.com>:
> Hi,
>
> In general, I'm a proponent of more frequent releases. We had some
> mails last year and the consensus that I remember was to have
> something around 3 or 4 releases per year would be the optimum
> (correct me if I'm wrong).
>
> How we number them ... well, as a matter of fact, Thrift is already
> widely used in production. The languages on the market and their
> capabilities are constantly changing and will continue to do so, and
> so is Thrift, because of it's very nature of being a
> connectivity-enabling framework. So more than with most other
> software, there will never be /the/ one, 100% complete and 100%
> final Thrift version, because things change and Thrift needs to be
> constantly adapted.
>
> Version numbers around 1.0 are more a kind of a psychological thing:
> Below 1.0, the project devs have more freedom with what they do,
> because "the product is not final". So you kinda fly under the
> radar. This changes with >= 1.0 and after. People are now looking
> more closely, but they also take the whole thing more seriously,
> because obviously someone considered it being "ready to market".
>
> Last not least, I personally have no strong opinions about the
> numbering scheme (anymore), so whatever decision we come up with,
> I'm fine with either one.
>
> @Aki: The original plans were to release 1.0 after 0.9.3. I added
> the 0.9.4 tag to JIRA, and that's how all of a sudden the plan
> started to change ... ;-)
>
> Have fun,
> JensG
>
>
>
> -----Ursprüngliche Nachricht----- From: Aki Sukegawa
> Sent: Saturday, January 9, 2016 7:48 PM
> To: dev@thrift.apache.org ; jfarrell@apache.org
> Subject: Re: Thoughts on a 0.9.4 rc
>
> Great to hear that !
> I have a few local WIP that would be valuable for the release but I think I
> can make it very soon.
>
> One thing I want to propose is to use a different versioning scheme,
> something like 0.10.0.
>
> Last time, I saw users complaining like "Why such a change for *patch*
> release ??"
> And this time we have quite a few behavior changes like wire-format for
> certain language+protocols or default generator flags for a language.
> So 0.9.4 would induce wrong expectation among users.
>
> I understand the original intention of 0.9.x series and glad we're almost
> finishing this.
> But if a different scheme communicates the release content better, isn't it
> worth compromising last a few release numbers before 1.0 ?
>
>
> On Sun, Jan 10, 2016 at 2:46 AM Jake Farrell <jf...@apache.org> wrote:
>
>> What does everyone think about cutting a 0.9.4 release candidate in the
>> next week or so?
>>
>> -Jake
>>
Re: Thoughts on a 0.9.4 rc
Posted by Jens Geyer <je...@hotmail.com>.
Hi,
In general, I'm a proponent of more frequent releases. We had some mails
last year and the consensus that I remember was to have something around 3
or 4 releases per year would be the optimum (correct me if I'm wrong).
How we number them ... well, as a matter of fact, Thrift is already widely
used in production. The languages on the market and their capabilities are
constantly changing and will continue to do so, and so is Thrift, because of
it's very nature of being a connectivity-enabling framework. So more than
with most other software, there will never be /the/ one, 100% complete and
100% final Thrift version, because things change and Thrift needs to be
constantly adapted.
Version numbers around 1.0 are more a kind of a psychological thing: Below
1.0, the project devs have more freedom with what they do, because "the
product is not final". So you kinda fly under the radar. This changes with
>= 1.0 and after. People are now looking more closely, but they also take
the whole thing more seriously, because obviously someone considered it
being "ready to market".
Last not least, I personally have no strong opinions about the numbering
scheme (anymore), so whatever decision we come up with, I'm fine with either
one.
@Aki: The original plans were to release 1.0 after 0.9.3. I added the 0.9.4
tag to JIRA, and that's how all of a sudden the plan started to change ...
;-)
Have fun,
JensG
-----Ursprüngliche Nachricht-----
From: Aki Sukegawa
Sent: Saturday, January 9, 2016 7:48 PM
To: dev@thrift.apache.org ; jfarrell@apache.org
Subject: Re: Thoughts on a 0.9.4 rc
Great to hear that !
I have a few local WIP that would be valuable for the release but I think I
can make it very soon.
One thing I want to propose is to use a different versioning scheme,
something like 0.10.0.
Last time, I saw users complaining like "Why such a change for *patch*
release ??"
And this time we have quite a few behavior changes like wire-format for
certain language+protocols or default generator flags for a language.
So 0.9.4 would induce wrong expectation among users.
I understand the original intention of 0.9.x series and glad we're almost
finishing this.
But if a different scheme communicates the release content better, isn't it
worth compromising last a few release numbers before 1.0 ?
On Sun, Jan 10, 2016 at 2:46 AM Jake Farrell <jf...@apache.org> wrote:
> What does everyone think about cutting a 0.9.4 release candidate in the
> next week or so?
>
> -Jake
>
Re: Thoughts on a 0.9.4 rc
Posted by Aki Sukegawa <ns...@apache.org>.
Great to hear that !
I have a few local WIP that would be valuable for the release but I think I
can make it very soon.
One thing I want to propose is to use a different versioning scheme,
something like 0.10.0.
Last time, I saw users complaining like "Why such a change for *patch*
release ??"
And this time we have quite a few behavior changes like wire-format for
certain language+protocols or default generator flags for a language.
So 0.9.4 would induce wrong expectation among users.
I understand the original intention of 0.9.x series and glad we're almost
finishing this.
But if a different scheme communicates the release content better, isn't it
worth compromising last a few release numbers before 1.0 ?
On Sun, Jan 10, 2016 at 2:46 AM Jake Farrell <jf...@apache.org> wrote:
> What does everyone think about cutting a 0.9.4 release candidate in the
> next week or so?
>
> -Jake
>