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 <eric.kl...@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 <mark.erick...@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 <d...@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 <jensge...@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 ; jfarr...@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 <jfarr...@apache.org>
wrote:
>
>> What does everyone think about cutting a 0.9.4 release candidate in the
>> next week or so?
>>
>> -Jake
>>
