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: [email protected] ; [email protected]
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 <[email protected]> wrote:
What does everyone think about cutting a 0.9.4 release candidate in the
next week or so?
-Jake
