Getting ready for Julia 0.3

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Getting ready for Julia 0.3

John Myles White
As Julia 0.3's release draws nearer, I'd like to make sure that most stats package:

(1) Release a stable version that works with 0.3 and tag a branch that will be used for 0.3 bugfix work going forward.

(2) Change the master branch to only work with 0.4, so that most users will be insulated from changes to master as we prepare for 0.4.

To do that, I'd like to see what people's priorities are for getting DataArrays and DataFrames ready for 0.3. This is mostly a question to devs, but it's also an invitation to anyone else to start working on any changes they think need to be made soon.

On my end, the main change I'd like to see land is my convert branch. (Which means I need to finish working on it.)

I don't have any other hi-pri changes in mind, but imagine there might be any.

Thoughts?

 -- John

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

Johan Sigfrids
As I understand it there will be a lot of breakage in 0.4 during the dev phase. It might not be a good idea to target 0.4 with package master branch until it stabilizes a bit.

OTOH there are a lot of nice things coming down the pipe for 0.4.

On Monday, August 18, 2014 6:05:53 PM UTC+3, John Myles White wrote:
As Julia 0.3’s release draws nearer, I’d like to make sure that most stats package:

(1) Release a stable version that works with 0.3 and tag a branch that will be used for 0.3 bugfix work going forward.

(2) Change the master branch to only work with 0.4, so that most users will be insulated from changes to master as we prepare for 0.4.

To do that, I’d like to see what people’s priorities are for getting DataArrays and DataFrames ready for 0.3. This is mostly a question to devs, but it’s also an invitation to anyone else to start working on any changes they think need to be made soon.

On my end, the main change I’d like to see land is my convert branch. (Which means I need to finish working on it.)

I don’t have any other hi-pri changes in mind, but imagine there might be any.

Thoughts?

 — John

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

John Myles White
That’s true.

But I’m also hoping to make a lot of breaking changes to DataFrames during the 0.4 cycle, so I’m not sure if we should wait for the breaking changes in 0.4 stop before we start testing out new parts of DataFrames.

 — John

On Aug 18, 2014, at 8:27 AM, Johan Sigfrids <[hidden email]> wrote:

As I understand it there will be a lot of breakage in 0.4 during the dev phase. It might not be a good idea to target 0.4 with package master branch until it stabilizes a bit.

OTOH there are a lot of nice things coming down the pipe for 0.4.

On Monday, August 18, 2014 6:05:53 PM UTC+3, John Myles White wrote:
As Julia 0.3’s release draws nearer, I’d like to make sure that most stats package:

(1) Release a stable version that works with 0.3 and tag a branch that will be used for 0.3 bugfix work going forward.

(2) Change the master branch to only work with 0.4, so that most users will be insulated from changes to master as we prepare for 0.4.

To do that, I’d like to see what people’s priorities are for getting DataArrays and DataFrames ready for 0.3. This is mostly a question to devs, but it’s also an invitation to anyone else to start working on any changes they think need to be made soon.

On my end, the main change I’d like to see land is my convert branch. (Which means I need to finish working on it.)

I don’t have any other hi-pri changes in mind, but imagine there might be any.

Thoughts?

 — John


--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

Johan Sigfrids
I was just thinking that if 0.4 keeps breaking the package then you may end up spending more time fixing the compatibility with 0.4 than developing new stuff. Then again, maybe fixing things as they break is easier in the long run than letting problems pile up and then having to do major surgery on the package to get it working.

On Monday, August 18, 2014 6:30:28 PM UTC+3, John Myles White wrote:
That’s true.

But I’m also hoping to make a lot of breaking changes to DataFrames during the 0.4 cycle, so I’m not sure if we should wait for the breaking changes in 0.4 stop before we start testing out new parts of DataFrames.

 — John

On Aug 18, 2014, at 8:27 AM, Johan Sigfrids <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="uHWALHxSCgUJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">johan.s...@...> wrote:

As I understand it there will be a lot of breakage in 0.4 during the dev phase. It might not be a good idea to target 0.4 with package master branch until it stabilizes a bit.

OTOH there are a lot of nice things coming down the pipe for 0.4.

On Monday, August 18, 2014 6:05:53 PM UTC+3, John Myles White wrote:
As Julia 0.3’s release draws nearer, I’d like to make sure that most stats package:

(1) Release a stable version that works with 0.3 and tag a branch that will be used for 0.3 bugfix work going forward.

(2) Change the master branch to only work with 0.4, so that most users will be insulated from changes to master as we prepare for 0.4.

To do that, I’d like to see what people’s priorities are for getting DataArrays and DataFrames ready for 0.3. This is mostly a question to devs, but it’s also an invitation to anyone else to start working on any changes they think need to be made soon.

On my end, the main change I’d like to see land is my convert branch. (Which means I need to finish working on it.)

I don’t have any other hi-pri changes in mind, but imagine there might be any.

Thoughts?

 — John


--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="uHWALHxSCgUJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">julia-stats...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

John Myles White
My feeling is that it’s easier to do work incrementally, but I might turn out to be wrong.

 — John

On Aug 18, 2014, at 8:49 AM, Johan Sigfrids <[hidden email]> wrote:

I was just thinking that if 0.4 keeps breaking the package then you may end up spending more time fixing the compatibility with 0.4 than developing new stuff. Then again, maybe fixing things as they break is easier in the long run than letting problems pile up and then having to do major surgery on the package to get it working. 

On Monday, August 18, 2014 6:30:28 PM UTC+3, John Myles White wrote:
That’s true.

But I’m also hoping to make a lot of breaking changes to DataFrames during the 0.4 cycle, so I’m not sure if we should wait for the breaking changes in 0.4 stop before we start testing out new parts of DataFrames.

 — John

On Aug 18, 2014, at 8:27 AM, Johan Sigfrids <johan.s...@gmail.com> wrote:

As I understand it there will be a lot of breakage in 0.4 during the dev phase. It might not be a good idea to target 0.4 with package master branch until it stabilizes a bit.

OTOH there are a lot of nice things coming down the pipe for 0.4.

On Monday, August 18, 2014 6:05:53 PM UTC+3, John Myles White wrote:
As Julia 0.3’s release draws nearer, I’d like to make sure that most stats package: 

(1) Release a stable version that works with 0.3 and tag a branch that will be used for 0.3 bugfix work going forward. 

(2) Change the master branch to only work with 0.4, so that most users will be insulated from changes to master as we prepare for 0.4. 

To do that, I’d like to see what people’s priorities are for getting DataArrays and DataFrames ready for 0.3. This is mostly a question to devs, but it’s also an invitation to anyone else to start working on any changes they think need to be made soon. 

On my end, the main change I’d like to see land is my convert branch. (Which means I need to finish working on it.) 

I don’t have any other hi-pri changes in mind, but imagine there might be any. 

Thoughts? 

 — John 


-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to julia-stats...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

Sean Garborg
I'm torn. For maybe the next nine months, users are going to be coming in on 0.3 and others are going to be staying there. It would be great for the 0.3 branch to see more than bugfixes, but with all the work to be done, I can't think of another solution that's not too onerous.

It couldn't hurt to encourage developers to keep non-breaking features/improvements separate from breaking ones where possible and backporting -- some packages will not go long before most new features are intertwined with previous breaking changes, but it still seems worth encouraging.


On Mon, Aug 18, 2014 at 11:52 AM, John Myles White <[hidden email]> wrote:
My feeling is that it’s easier to do work incrementally, but I might turn out to be wrong.

 — John

On Aug 18, 2014, at 8:49 AM, Johan Sigfrids <[hidden email]> wrote:

I was just thinking that if 0.4 keeps breaking the package then you may end up spending more time fixing the compatibility with 0.4 than developing new stuff. Then again, maybe fixing things as they break is easier in the long run than letting problems pile up and then having to do major surgery on the package to get it working. 

On Monday, August 18, 2014 6:30:28 PM UTC+3, John Myles White wrote:
That’s true.

But I’m also hoping to make a lot of breaking changes to DataFrames during the 0.4 cycle, so I’m not sure if we should wait for the breaking changes in 0.4 stop before we start testing out new parts of DataFrames.

 — John

On Aug 18, 2014, at 8:27 AM, Johan Sigfrids <johan.s...@gmail.com> wrote:

As I understand it there will be a lot of breakage in 0.4 during the dev phase. It might not be a good idea to target 0.4 with package master branch until it stabilizes a bit.

OTOH there are a lot of nice things coming down the pipe for 0.4.

On Monday, August 18, 2014 6:05:53 PM UTC+3, John Myles White wrote:
As Julia 0.3’s release draws nearer, I’d like to make sure that most stats package: 

(1) Release a stable version that works with 0.3 and tag a branch that will be used for 0.3 bugfix work going forward. 

(2) Change the master branch to only work with 0.4, so that most users will be insulated from changes to master as we prepare for 0.4. 

To do that, I’d like to see what people’s priorities are for getting DataArrays and DataFrames ready for 0.3. This is mostly a question to devs, but it’s also an invitation to anyone else to start working on any changes they think need to be made soon. 

On my end, the main change I’d like to see land is my convert branch. (Which means I need to finish working on it.) 

I don’t have any other hi-pri changes in mind, but imagine there might be any. 

Thoughts? 

 — John 


-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to julia-stats...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

Simon Kornblith
In reply to this post by John Myles White
We should also:

(3) Add a link to the documentation for the 0.3 branch to the top of README.md (or else commit to maintaining full API compatibility between the 0.3 branch and master).

Simon

On Monday, August 18, 2014 11:05:53 AM UTC-4, John Myles White wrote:
As Julia 0.3’s release draws nearer, I’d like to make sure that most stats package:

(1) Release a stable version that works with 0.3 and tag a branch that will be used for 0.3 bugfix work going forward.

(2) Change the master branch to only work with 0.4, so that most users will be insulated from changes to master as we prepare for 0.4.

To do that, I’d like to see what people’s priorities are for getting DataArrays and DataFrames ready for 0.3. This is mostly a question to devs, but it’s also an invitation to anyone else to start working on any changes they think need to be made soon.

On my end, the main change I’d like to see land is my convert branch. (Which means I need to finish working on it.)

I don’t have any other hi-pri changes in mind, but imagine there might be any.

Thoughts?

 — John

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

John Myles White
Since we've got a Read the Docs setup, I was thinking we should keep full versioned docs around if we can manage it.

 -- John

On Aug 18, 2014, at 11:41 AM, Simon Kornblith <[hidden email]> wrote:

We should also:

(3) Add a link to the documentation for the 0.3 branch to the top of README.md (or else commit to maintaining full API compatibility between the 0.3 branch and master).

Simon

On Monday, August 18, 2014 11:05:53 AM UTC-4, John Myles White wrote:
As Julia 0.3’s release draws nearer, I’d like to make sure that most stats package:

(1) Release a stable version that works with 0.3 and tag a branch that will be used for 0.3 bugfix work going forward.

(2) Change the master branch to only work with 0.4, so that most users will be insulated from changes to master as we prepare for 0.4.

To do that, I’d like to see what people’s priorities are for getting DataArrays and DataFrames ready for 0.3. This is mostly a question to devs, but it’s also an invitation to anyone else to start working on any changes they think need to be made soon.

On my end, the main change I’d like to see land is my convert branch. (Which means I need to finish working on it.)

I don’t have any other hi-pri changes in mind, but imagine there might be any.

Thoughts?

 — John


--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

Cameron McBride
In reply to this post by Sean Garborg
From a non-dev perspective (weight appropriately, consider this from the peanut gallery), I would be a bit disappointed if package development went the same way as 0.2, where it felt obsolete very quickly.  Packages just moved on, and most new users on the list were encouraged to "try the package with master (pre-0.3)".  Almost *every* scientist that I convinced to give Julia a try did the same thing: download a "release" version (even when advised not to in the beginning) and comment on some breakage.

To advocate Julia, I feel it's really helpful to have things work well on a release version.  The language might have a feature freeze, but I can't see why packages should target this, too.  At least, not until much later or when there are significant reasons to target new features.

Am I alone in thinking this? 

Cameron


On Mon, Aug 18, 2014 at 1:03 PM, Sean Garborg <[hidden email]> wrote:
I'm torn. For maybe the next nine months, users are going to be coming in on 0.3 and others are going to be staying there. It would be great for the 0.3 branch to see more than bugfixes, but with all the work to be done, I can't think of another solution that's not too onerous.

It couldn't hurt to encourage developers to keep non-breaking features/improvements separate from breaking ones where possible and backporting -- some packages will not go long before most new features are intertwined with previous breaking changes, but it still seems worth encouraging.


On Mon, Aug 18, 2014 at 11:52 AM, John Myles White <[hidden email]> wrote:
My feeling is that it’s easier to do work incrementally, but I might turn out to be wrong.

 — John

On Aug 18, 2014, at 8:49 AM, Johan Sigfrids <[hidden email]> wrote:

I was just thinking that if 0.4 keeps breaking the package then you may end up spending more time fixing the compatibility with 0.4 than developing new stuff. Then again, maybe fixing things as they break is easier in the long run than letting problems pile up and then having to do major surgery on the package to get it working. 

On Monday, August 18, 2014 6:30:28 PM UTC+3, John Myles White wrote:
That’s true.

But I’m also hoping to make a lot of breaking changes to DataFrames during the 0.4 cycle, so I’m not sure if we should wait for the breaking changes in 0.4 stop before we start testing out new parts of DataFrames.

 — John

On Aug 18, 2014, at 8:27 AM, Johan Sigfrids <johan.s...@gmail.com> wrote:

As I understand it there will be a lot of breakage in 0.4 during the dev phase. It might not be a good idea to target 0.4 with package master branch until it stabilizes a bit.

OTOH there are a lot of nice things coming down the pipe for 0.4.

On Monday, August 18, 2014 6:05:53 PM UTC+3, John Myles White wrote:
As Julia 0.3’s release draws nearer, I’d like to make sure that most stats package: 

(1) Release a stable version that works with 0.3 and tag a branch that will be used for 0.3 bugfix work going forward. 

(2) Change the master branch to only work with 0.4, so that most users will be insulated from changes to master as we prepare for 0.4. 

To do that, I’d like to see what people’s priorities are for getting DataArrays and DataFrames ready for 0.3. This is mostly a question to devs, but it’s also an invitation to anyone else to start working on any changes they think need to be made soon. 

On my end, the main change I’d like to see land is my convert branch. (Which means I need to finish working on it.) 

I don’t have any other hi-pri changes in mind, but imagine there might be any. 

Thoughts? 

 — John 


-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to julia-stats...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

John Myles White
A couple of responses:

(1) We (above all, me) did a very bad job with the 0.2 -> 0.3 transition. Partly this is a timing issue: the 0.2 -> 0.3 transition happened right as I started my new job, which let me with a lot less time to work on Julia. Luckily a bunch of smart folks (Simon and Sean in particular) have started doing a lot of work without waitng for me to give input. That's kept things functioning, even if it's been a very bumpy ride.

To do better, we need to make sure that there's a fixed version of every "core" package that's 0.3 compatible. We need to create a walled off environment in which everything just works if you're installing 0.3, whether it's DataFrames or StatsBase. We also need to keep docs separate for 0.3 so that you only see information that's relevant to the release you're working with.

(2) At the same time, there's so many breaking changes that we need freedom to make. So I think it's important that we have the freedom to develop in a 0.4 branch without any expectation that non-devs will use that branch.

We also don't really have the engineering resources to backport features to 0.3. (We barely have the resources to push 0.4 forward.) So I think it's important that there's a clear statement that the 0.3 ecosystem is what it is. If it's sufficient, you're set. If it's not sufficient, you're on your own. The only changes that you should expect to see to 0.3 releases are bug fixes.

(3) Regarding the expectations of scientists, I've come to realize I substantially overestimated the programming background of most scientists. My sense is that we're starting to hit a better spot, where the people coming to Julia now tend to be much more technical than people in the past. But I'm still not sure if we're pitching Julia in the right way.

 -- John

On Aug 18, 2014, at 11:46 AM, Cameron McBride <[hidden email]> wrote:

From a non-dev perspective (weight appropriately, consider this from the peanut gallery), I would be a bit disappointed if package development went the same way as 0.2, where it felt obsolete very quickly.  Packages just moved on, and most new users on the list were encouraged to "try the package with master (pre-0.3)".  Almost *every* scientist that I convinced to give Julia a try did the same thing: download a "release" version (even when advised not to in the beginning) and comment on some breakage.

To advocate Julia, I feel it's really helpful to have things work well on a release version.  The language might have a feature freeze, but I can't see why packages should target this, too.  At least, not until much later or when there are significant reasons to target new features.

Am I alone in thinking this? 

Cameron


On Mon, Aug 18, 2014 at 1:03 PM, Sean Garborg <[hidden email]> wrote:
I'm torn. For maybe the next nine months, users are going to be coming in on 0.3 and others are going to be staying there. It would be great for the 0.3 branch to see more than bugfixes, but with all the work to be done, I can't think of another solution that's not too onerous.

It couldn't hurt to encourage developers to keep non-breaking features/improvements separate from breaking ones where possible and backporting -- some packages will not go long before most new features are intertwined with previous breaking changes, but it still seems worth encouraging.


On Mon, Aug 18, 2014 at 11:52 AM, John Myles White <[hidden email]> wrote:
My feeling is that it’s easier to do work incrementally, but I might turn out to be wrong.

 — John

On Aug 18, 2014, at 8:49 AM, Johan Sigfrids <[hidden email]> wrote:

I was just thinking that if 0.4 keeps breaking the package then you may end up spending more time fixing the compatibility with 0.4 than developing new stuff. Then again, maybe fixing things as they break is easier in the long run than letting problems pile up and then having to do major surgery on the package to get it working. 

On Monday, August 18, 2014 6:30:28 PM UTC+3, John Myles White wrote:
That’s true.

But I’m also hoping to make a lot of breaking changes to DataFrames during the 0.4 cycle, so I’m not sure if we should wait for the breaking changes in 0.4 stop before we start testing out new parts of DataFrames.

 — John

On Aug 18, 2014, at 8:27 AM, Johan Sigfrids <johan.s...@gmail.com> wrote:

As I understand it there will be a lot of breakage in 0.4 during the dev phase. It might not be a good idea to target 0.4 with package master branch until it stabilizes a bit.

OTOH there are a lot of nice things coming down the pipe for 0.4.

On Monday, August 18, 2014 6:05:53 PM UTC+3, John Myles White wrote:
As Julia 0.3’s release draws nearer, I’d like to make sure that most stats package: 

(1) Release a stable version that works with 0.3 and tag a branch that will be used for 0.3 bugfix work going forward. 

(2) Change the master branch to only work with 0.4, so that most users will be insulated from changes to master as we prepare for 0.4. 

To do that, I’d like to see what people’s priorities are for getting DataArrays and DataFrames ready for 0.3. This is mostly a question to devs, but it’s also an invitation to anyone else to start working on any changes they think need to be made soon. 

On my end, the main change I’d like to see land is my convert branch. (Which means I need to finish working on it.) 

I don’t have any other hi-pri changes in mind, but imagine there might be any. 

Thoughts? 

 — John 


-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to julia-stats...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

Cameron McBride
I guess what I was trying to suggest was not that "we" bifurcate the effort to dev and backporting to 0.3, but instead to target development on 0.3 branches unless there is a Really Good Reason to move to the 0.4 language base.  Breaking changes of DataFrames can still target Julia 0.3, right? 

And FWIW, JuliaStats was not the only group to have a bumpy 0.2 to 0.3 transition.

On Mon, Aug 18, 2014 at 3:03 PM, John Myles White <[hidden email]> wrote:
(3) Regarding the expectations of scientists, I've come to realize I substantially overestimated the programming background of most scientists. My sense is that we're starting to hit a better spot, where the people coming to Julia now tend to be much more technical than people in the past. But I'm still not sure if we're pitching Julia in the right way.

This statement cracked me up.   Thank you. 

From my experience in a tech savvy branch of science -- the appropriate level to target is difficult to determine.  Even those that "know better", rarely spend the time to "do better" (for a variety of reasons).  We might write some crufty code, and continually find bugs, yet the tolerance for the system (language, package, etc.) having bugs is apparently very, very low.

I imagine the "right" pitch for Julia will vary a lot by field / sub-field. 

Cameron

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

John Myles White
I think there are two questions here:

(1) Do breaking changes need to happen on 0.4 or can they happen on 0.3?

(2) How do we make sure that breaking changes won't affect users of 0.3?

Re. (1), I think we could do development against 0.3 for a while. I'm actually doing that right now. But we're going to want to target 0.4 as soon as 0.4 changes the indexing rules for arrays since DataArrays will need to sync up with that behavior. So we have to move to 0.4 at some point. I think it's easier to make that move sooner rather than later, but we could put it off for a while.

Re. (2), I don't see any way to have any point releases of master without using 0.4 as a way to discriminate between stable and dev version fo DataFrames. We could handle this by only providing point releases for 0.3, so that METADATA would never give you access to the devel state of DataFrames. That might be a reasonable thing to do to emphasize that DataFrames is in state of flux.

Regarding your last point about tolerances for bugs, I think part of the difficulty is that most people view a programming language as a tool they would employ rather than a community they would participate in. Even though Julia's open source, many people treat it like a commerical product that the developers should be selling to them, rather than a project that anyone can choose to participate in. This has become something I'm sadder and sadder about, since it's very different from working at Facebook, where people tend to assume that if some system's broken, they're the ones who should go fix it. ("Nothing is someone else's problem" is actually one of our internal mottos.)

 -- John

On Aug 18, 2014, at 12:35 PM, Cameron McBride <[hidden email]> wrote:

I guess what I was trying to suggest was not that "we" bifurcate the effort to dev and backporting to 0.3, but instead to target development on 0.3 branches unless there is a Really Good Reason to move to the 0.4 language base.  Breaking changes of DataFrames can still target Julia 0.3, right? 

And FWIW, JuliaStats was not the only group to have a bumpy 0.2 to 0.3 transition.

On Mon, Aug 18, 2014 at 3:03 PM, John Myles White <[hidden email]> wrote:
(3) Regarding the expectations of scientists, I've come to realize I substantially overestimated the programming background of most scientists. My sense is that we're starting to hit a better spot, where the people coming to Julia now tend to be much more technical than people in the past. But I'm still not sure if we're pitching Julia in the right way.

This statement cracked me up.   Thank you. 

From my experience in a tech savvy branch of science -- the appropriate level to target is difficult to determine.  Even those that "know better", rarely spend the time to "do better" (for a variety of reasons).  We might write some crufty code, and continually find bugs, yet the tolerance for the system (language, package, etc.) having bugs is apparently very, very low.

I imagine the "right" pitch for Julia will vary a lot by field / sub-field. 

Cameron

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

Simon Kornblith
On Monday, August 18, 2014 4:04:39 PM UTC-4, John Myles White wrote:
I think there are two questions here:

(1) Do breaking changes need to happen on 0.4 or can they happen on 0.3?

(2) How do we make sure that breaking changes won't affect users of 0.3?

Re. (1), I think we could do development against 0.3 for a while. I'm actually doing that right now. But we're going to want to target 0.4 as soon as 0.4 changes the indexing rules for arrays since DataArrays will need to sync up with that behavior. So we have to move to 0.4 at some point. I think it's easier to make that move sooner rather than later, but we could put it off for a while.

Re. (2), I don't see any way to have any point releases of master without using 0.4 as a way to discriminate between stable and dev version fo DataFrames. We could handle this by only providing point releases for 0.3, so that METADATA would never give you access to the devel state of DataFrames. That might be a reasonable thing to do to emphasize that DataFrames is in state of flux.

Regarding your last point about tolerances for bugs, I think part of the difficulty is that most people view a programming language as a tool they would employ rather than a community they would participate in. Even though Julia's open source, many people treat it like a commerical product that the developers should be selling to them, rather than a project that anyone can choose to participate in. This has become something I'm sadder and sadder about, since it's very different from working at Facebook, where people tend to assume that if some system's broken, they're the ones who should go fix it. ("Nothing is someone else's problem" is actually one of our internal mottos.)

Generally, I think Julia's ecosystem is far better in this regard than other open source projects I've worked on, which have a handful of regular contributors, a handful more occasional contributors, and >1 million users. Julia users are generally early adopters who know how to code well enough that picking up a new programming language isn't a big deal, and a substantial proportion (although not the majority) do actually contribute. I'm confident that we'll continue to attract new contributors in the future, but the contributor to user ratio is only going to go down from here.

In general, I think the problem with maintaining code for old releases is precisely that Julia is a community-driven project and most contributors use the latest master. People who are writing code in their spare time are not particularly inclined to spend that time coding things that 1) don't affect them and 2) will become obsolete when the next version is released. This is something that will resolve itself with time as the language stabilizes and it becomes easier to write code that works with both the last release and latest master. I'm hopeful most of the breaking changes will be over by the time 0.4 is released and it will be easier to maintain compatibility between 0.4 and 0.5, but we know that 0.4 will be a particularly difficult transition. I realize that this may detract from our user base, but for now, I don't really see a solution.

Simon

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

Iain Dunning
An unsolicited thought on versioning:

DataFrames, for example, is on v0.5.7 right now. Something that seems sensible to me, right now at least is:

1. Release a new version v0.6.0
2. Create a release06 or julia03 branch on DataFrames.jl at this commit
3. First Julia 0.4 only release gets a new minor version v0.7.0
4. Any fixes on the old version go in the v0.6.x line.

Alternatively, keep the 0.5.x line as the Julia 0.3 line, make 0.6.x the Julia 0.4 line. Anyway, I think its something we should be making explicit to package maintainers, because I think that even pre 1.0 versions can have some signals encoded in the release numbers.

JuMP was easy to keep working on 0.2 and 0.3, relative to other packages, but there are a lot of goodies on 0.4 that are going to mean we will want to make a split much sooner...

Still, nothing needs to *break* on 0.3 which is the important thing, and we have the experience and tooling now to avoid that.

Exciting times!

On Monday, August 18, 2014 8:31:28 PM UTC-4, Simon Kornblith wrote:
On Monday, August 18, 2014 4:04:39 PM UTC-4, John Myles White wrote:
I think there are two questions here:

(1) Do breaking changes need to happen on 0.4 or can they happen on 0.3?

(2) How do we make sure that breaking changes won't affect users of 0.3?

Re. (1), I think we could do development against 0.3 for a while. I'm actually doing that right now. But we're going to want to target 0.4 as soon as 0.4 changes the indexing rules for arrays since DataArrays will need to sync up with that behavior. So we have to move to 0.4 at some point. I think it's easier to make that move sooner rather than later, but we could put it off for a while.

Re. (2), I don't see any way to have any point releases of master without using 0.4 as a way to discriminate between stable and dev version fo DataFrames. We could handle this by only providing point releases for 0.3, so that METADATA would never give you access to the devel state of DataFrames. That might be a reasonable thing to do to emphasize that DataFrames is in state of flux.

Regarding your last point about tolerances for bugs, I think part of the difficulty is that most people view a programming language as a tool they would employ rather than a community they would participate in. Even though Julia's open source, many people treat it like a commerical product that the developers should be selling to them, rather than a project that anyone can choose to participate in. This has become something I'm sadder and sadder about, since it's very different from working at Facebook, where people tend to assume that if some system's broken, they're the ones who should go fix it. ("Nothing is someone else's problem" is actually one of our internal mottos.)

Generally, I think Julia's ecosystem is far better in this regard than other open source projects I've worked on, which have a handful of regular contributors, a handful more occasional contributors, and >1 million users. Julia users are generally early adopters who know how to code well enough that picking up a new programming language isn't a big deal, and a substantial proportion (although not the majority) do actually contribute. I'm confident that we'll continue to attract new contributors in the future, but the contributor to user ratio is only going to go down from here.

In general, I think the problem with maintaining code for old releases is precisely that Julia is a community-driven project and most contributors use the latest master. People who are writing code in their spare time are not particularly inclined to spend that time coding things that 1) don't affect them and 2) will become obsolete when the next version is released. This is something that will resolve itself with time as the language stabilizes and it becomes easier to write code that works with both the last release and latest master. I'm hopeful most of the breaking changes will be over by the time 0.4 is released and it will be easier to maintain compatibility between 0.4 and 0.5, but we know that 0.4 will be a particularly difficult transition. I realize that this may detract from our user base, but for now, I don't really see a solution.

Simon

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

David Anthoff

One vote for keeping the package masters on julia 0.3 for as long as possible.

 

There are really two issues: 1) obviously what really shouldn’t happen is that packages don’t work on 0.3 (i.e. what happened with 0.2), but my sense is that this can be achieved by packages maintainers being careful and keeping a frozen version that targets julia 0.3. But issue 2) is whether for users of julia 0.3 packages will see no improvements other than bug fixes until julia 0.4 will be released. I think if that were to happen it would be unfortunate. Things just start to feel “stale”, users will ask “how can I do X” and people will answer “use julia pre 0.4, because we implemented this in a package that targets a dev version” etc.

 

I would MUCH prefer that normal package development continues to target julia 0.3 as long as possible, so that as a user I don’t feel that I’m way behind the curve in a few months already. I think that would generally also add a great deal to make julia and its package eco system somewhat usable and stable to “normal” users.

 

I see that at some point this won’t work (e.g. the changes to indexing in 0.4 Miles mentioned), but I would suggest people go out of their way to make the switch of the master of a package to julia 0.4 as late as possible.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Iain Dunning
Sent: Monday, August 18, 2014 6:12 PM
To: [hidden email]
Subject: Re: [julia-stats] Re: Getting ready for Julia 0.3

 

An unsolicited thought on versioning:

 

DataFrames, for example, is on v0.5.7 right now. Something that seems sensible to me, right now at least is:

 

1. Release a new version v0.6.0

2. Create a release06 or julia03 branch on DataFrames.jl at this commit

3. First Julia 0.4 only release gets a new minor version v0.7.0

4. Any fixes on the old version go in the v0.6.x line.

 

Alternatively, keep the 0.5.x line as the Julia 0.3 line, make 0.6.x the Julia 0.4 line. Anyway, I think its something we should be making explicit to package maintainers, because I think that even pre 1.0 versions can have some signals encoded in the release numbers.

 

JuMP was easy to keep working on 0.2 and 0.3, relative to other packages, but there are a lot of goodies on 0.4 that are going to mean we will want to make a split much sooner...

 

Still, nothing needs to *break* on 0.3 which is the important thing, and we have the experience and tooling now to avoid that.

 

Exciting times!


On Monday, August 18, 2014 8:31:28 PM UTC-4, Simon Kornblith wrote:

On Monday, August 18, 2014 4:04:39 PM UTC-4, John Myles White wrote:

I think there are two questions here:

 

(1) Do breaking changes need to happen on 0.4 or can they happen on 0.3?

 

(2) How do we make sure that breaking changes won't affect users of 0.3?

 

Re. (1), I think we could do development against 0.3 for a while. I'm actually doing that right now. But we're going to want to target 0.4 as soon as 0.4 changes the indexing rules for arrays since DataArrays will need to sync up with that behavior. So we have to move to 0.4 at some point. I think it's easier to make that move sooner rather than later, but we could put it off for a while.

 

Re. (2), I don't see any way to have any point releases of master without using 0.4 as a way to discriminate between stable and dev version fo DataFrames. We could handle this by only providing point releases for 0.3, so that METADATA would never give you access to the devel state of DataFrames. That might be a reasonable thing to do to emphasize that DataFrames is in state of flux.

 

Regarding your last point about tolerances for bugs, I think part of the difficulty is that most people view a programming language as a tool they would employ rather than a community they would participate in. Even though Julia's open source, many people treat it like a commerical product that the developers should be selling to them, rather than a project that anyone can choose to participate in. This has become something I'm sadder and sadder about, since it's very different from working at Facebook, where people tend to assume that if some system's broken, they're the ones who should go fix it. ("Nothing is someone else's problem" is actually one of our internal mottos.)

 

Generally, I think Julia's ecosystem is far better in this regard than other open source projects I've worked on, which have a handful of regular contributors, a handful more occasional contributors, and >1 million users. Julia users are generally early adopters who know how to code well enough that picking up a new programming language isn't a big deal, and a substantial proportion (although not the majority) do actually contribute. I'm confident that we'll continue to attract new contributors in the future, but the contributor to user ratio is only going to go down from here.

 

In general, I think the problem with maintaining code for old releases is precisely that Julia is a community-driven project and most contributors use the latest master. People who are writing code in their spare time are not particularly inclined to spend that time coding things that 1) don't affect them and 2) will become obsolete when the next version is released. This is something that will resolve itself with time as the language stabilizes and it becomes easier to write code that works with both the last release and latest master. I'm hopeful most of the breaking changes will be over by the time 0.4 is released and it will be easier to maintain compatibility between 0.4 and 0.5, but we know that 0.4 will be a particularly difficult transition. I realize that this may detract from our user base, but for now, I don't really see a solution.

 

Simon

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

John Myles White
I broadly agree with Iain's suggestions. But I also disagree with some of your suggestions, David.

In particular, I think the response to, "how can I do X?", is simply "you can't do this yet. Wait for 0.4 in a few months."

The only way we can offer new functionality for the 0.3 release is if there's new people coming into the community who are willing to volunteer to handle backporting features to 0.3. Absent new people stepping up to do that work, I think it's a misuse of our resources to port features back to 0.3 -- especially because the features I'm interested in getting finished for 0.4 all interact with one another and can't be used in isolation. As such, trying to do backporting is like doubling the amount of work we have to do. If people want to volunteer to do that work, that would be great. But I don't think we can reasonably agree to do that work without a substantial influx of new developers, each dedicating a substantial amount of work time per week.

Given the constained resources we have, I think there are two tracks people are allowed to select into:

(1) End users, who don't do development work and receive non-bugfix changes on a 6-8 month schedule. Their problems are easier to debug if they're all going to be working with exactly one point release, not a gradually shifting master release. Much of what made debugging so hard in the last cycle was that 0.2 was clearly dead, but lots of people weren't keeping up with the dev branch by doing updates every day. So they reported problems that couldn't be reproduced without doing a huge amount of work. That's something we need to completely prevent in the future.

(2) Developers, who are expected to resolve any bugs they hit for themselves. The assumption is always that developers work with the bleeding edge of everything because they track changes on a daily basis and are subscribed to all of the repos they work on.

 -- John

On Aug 19, 2014, at 11:14 AM, David Anthoff <[hidden email]> wrote:

One vote for keeping the package masters on julia 0.3 for as long as possible.
 
There are really two issues: 1) obviously what really shouldn’t happen is that packages don’t work on 0.3 (i.e. what happened with 0.2), but my sense is that this can be achieved by packages maintainers being careful and keeping a frozen version that targets julia 0.3. But issue 2) is whether for users of julia 0.3 packages will see no improvements other than bug fixes until julia 0.4 will be released. I think if that were to happen it would be unfortunate. Things just start to feel “stale”, users will ask “how can I do X” and people will answer “use julia pre 0.4, because we implemented this in a package that targets a dev version” etc.
 
I would MUCH prefer that normal package development continues to target julia 0.3 as long as possible, so that as a user I don’t feel that I’m way behind the curve in a few months already. I think that would generally also add a great deal to make julia and its package eco system somewhat usable and stable to “normal” users.
 
I see that at some point this won’t work (e.g. the changes to indexing in 0.4 Miles mentioned), but I would suggest people go out of their way to make the switch of the master of a package to julia 0.4 as late as possible.
 
From: [hidden email] [[hidden email]] On Behalf Of Iain Dunning
Sent: Monday, August 18, 2014 6:12 PM
To: [hidden email]
Subject: Re: [julia-stats] Re: Getting ready for Julia 0.3
 
An unsolicited thought on versioning:
 
DataFrames, for example, is on v0.5.7 right now. Something that seems sensible to me, right now at least is:
 
1. Release a new version v0.6.0
2. Create a release06 or julia03 branch on DataFrames.jl at this commit
3. First Julia 0.4 only release gets a new minor version v0.7.0
4. Any fixes on the old version go in the v0.6.x line.
 
Alternatively, keep the 0.5.x line as the Julia 0.3 line, make 0.6.x the Julia 0.4 line. Anyway, I think its something we should be making explicit to package maintainers, because I think that even pre 1.0 versions can have some signals encoded in the release numbers.
 
JuMP was easy to keep working on 0.2 and 0.3, relative to other packages, but there are a lot of goodies on 0.4 that are going to mean we will want to make a split much sooner...
 
Still, nothing needs to *break* on 0.3 which is the important thing, and we have the experience and tooling now to avoid that.
 
Exciting times!

On Monday, August 18, 2014 8:31:28 PM UTC-4, Simon Kornblith wrote:
On Monday, August 18, 2014 4:04:39 PM UTC-4, John Myles White wrote:
I think there are two questions here:
 
(1) Do breaking changes need to happen on 0.4 or can they happen on 0.3?
 
(2) How do we make sure that breaking changes won't affect users of 0.3?
 
Re. (1), I think we could do development against 0.3 for a while. I'm actually doing that right now. But we're going to want to target 0.4 as soon as 0.4 changes the indexing rules for arrays since DataArrays will need to sync up with that behavior. So we have to move to 0.4 at some point. I think it's easier to make that move sooner rather than later, but we could put it off for a while.
 
Re. (2), I don't see any way to have any point releases of master without using 0.4 as a way to discriminate between stable and dev version fo DataFrames. We could handle this by only providing point releases for 0.3, so that METADATA would never give you access to the devel state of DataFrames. That might be a reasonable thing to do to emphasize that DataFrames is in state of flux.
 
Regarding your last point about tolerances for bugs, I think part of the difficulty is that most people view a programming language as a tool they would employ rather than a community they would participate in. Even though Julia's open source, many people treat it like a commerical product that the developers should be selling to them, rather than a project that anyone can choose to participate in. This has become something I'm sadder and sadder about, since it's very different from working at Facebook, where people tend to assume that if some system's broken, they're the ones who should go fix it. ("Nothing is someone else's problem" is actually one of our internal mottos.)
 
Generally, I think Julia's ecosystem is far better in this regard than other open source projects I've worked on, which have a handful of regular contributors, a handful more occasional contributors, and >1 million users. Julia users are generally early adopters who know how to code well enough that picking up a new programming language isn't a big deal, and a substantial proportion (although not the majority) do actually contribute. I'm confident that we'll continue to attract new contributors in the future, but the contributor to user ratio is only going to go down from here.
 
In general, I think the problem with maintaining code for old releases is precisely that Julia is a community-driven project and most contributors use the latest master. People who are writing code in their spare time are not particularly inclined to spend that time coding things that 1) don't affect them and 2) will become obsolete when the next version is released. This is something that will resolve itself with time as the language stabilizes and it becomes easier to write code that works with both the last release and latest master. I'm hopeful most of the breaking changes will be over by the time 0.4 is released and it will be easier to maintain compatibility between 0.4 and 0.5, but we know that 0.4 will be a particularly difficult transition. I realize that this may detract from our user base, but for now, I don't really see a solution.
 
Simon
-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

Gray Calhoun
On Tuesday, August 19, 2014 1:46:46 PM UTC-5, John Myles White wrote:
The only way we can offer new functionality for the 0.3 release is if there's new people coming into the community who are willing to volunteer to handle backporting features to 0.3. Absent new people stepping up to do that work, I think it's a misuse of our resources to port features back to 0.3 -- especially because the features I'm interested in getting finished for 0.4 all interact with one another and can't be used in isolation. As such, trying to do backporting is like doubling the amount of work we have to do. If people want to volunteer to do that work, that would be great. But I don't think we can reasonably agree to do that work without a substantial influx of new developers, each dedicating a substantial amount of work time per week.

As someone who's done far less development than I should... this seems like completely the right priority.

Also, people should realize that package maintainers have been very willing to accept and coach people through pull requests. So if anyone needs to backport a new feature for their own use (teaching, research etc) it's very likely that the feature will be accepted and distributed for the 0.3 "version" of the package -- i.e. the 0.6.x line from Iain's DataFrames example.

Once there's a set plan, it might be worth writing up a brief "how to backport a feature from v0.4.0" document, just to have a link to direct people. And just to be clear, "it might be worth writing" means "if other people think it's a good idea, I will happily type up and format such a document, so long as someone tells me where it goes."

--Gray Calhoun

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

David Anthoff
In reply to this post by John Myles White

I didn’t mean to suggest stuff should be back ported, I agree that would just be a waste of time. What I am suggesting is that packages that can be developed further without a dependency on new julia 0.4 features should have their master continue target julia 0.3 for as long as possible. DataFrames might not be one of those, but I am sure there are countless other packages where there really is no need at this point to make their active branch depend on julia 0.4. Maybe an example is Distributions.jl, couldn’t its master stay on julia 0.3 for quite a while, get new features for a couple of months before it starts to depend on julia 0.4? If it is not Distributions.jl, I’m sure there are other packages where this would be true. I read your original mail as suggesting “all packages in julia-stats should switch their master to 0.4 now”, and I would prefer to have the message be “if your package requires something in julia 0.4, switch, otherwise try to stay on julia 0.3 for a while”.

 

Cheers,

David

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of John Myles White
Sent: Tuesday, August 19, 2014 11:47 AM
To: [hidden email]
Subject: Re: [julia-stats] Re: Getting ready for Julia 0.3

 

I broadly agree with Iain's suggestions. But I also disagree with some of your suggestions, David.

 

In particular, I think the response to, "how can I do X?", is simply "you can't do this yet. Wait for 0.4 in a few months."

 

The only way we can offer new functionality for the 0.3 release is if there's new people coming into the community who are willing to volunteer to handle backporting features to 0.3. Absent new people stepping up to do that work, I think it's a misuse of our resources to port features back to 0.3 -- especially because the features I'm interested in getting finished for 0.4 all interact with one another and can't be used in isolation. As such, trying to do backporting is like doubling the amount of work we have to do. If people want to volunteer to do that work, that would be great. But I don't think we can reasonably agree to do that work without a substantial influx of new developers, each dedicating a substantial amount of work time per week.

 

Given the constained resources we have, I think there are two tracks people are allowed to select into:

 

(1) End users, who don't do development work and receive non-bugfix changes on a 6-8 month schedule. Their problems are easier to debug if they're all going to be working with exactly one point release, not a gradually shifting master release. Much of what made debugging so hard in the last cycle was that 0.2 was clearly dead, but lots of people weren't keeping up with the dev branch by doing updates every day. So they reported problems that couldn't be reproduced without doing a huge amount of work. That's something we need to completely prevent in the future.

 

(2) Developers, who are expected to resolve any bugs they hit for themselves. The assumption is always that developers work with the bleeding edge of everything because they track changes on a daily basis and are subscribed to all of the repos they work on.

 

 -- John

 

On Aug 19, 2014, at 11:14 AM, David Anthoff <[hidden email]> wrote:



One vote for keeping the package masters on julia 0.3 for as long as possible.

 

There are really two issues: 1) obviously what really shouldn’t happen is that packages don’t work on 0.3 (i.e. what happened with 0.2), but my sense is that this can be achieved by packages maintainers being careful and keeping a frozen version that targets julia 0.3. But issue 2) is whether for users of julia 0.3 packages will see no improvements other than bug fixes until julia 0.4 will be released. I think if that were to happen it would be unfortunate. Things just start to feel “stale”, users will ask “how can I do X” and people will answer “use julia pre 0.4, because we implemented this in a package that targets a dev version” etc.

 

I would MUCH prefer that normal package development continues to target julia 0.3 as long as possible, so that as a user I don’t feel that I’m way behind the curve in a few months already. I think that would generally also add a great deal to make julia and its package eco system somewhat usable and stable to “normal” users.

 

I see that at some point this won’t work (e.g. the changes to indexing in 0.4 Miles mentioned), but I would suggest people go out of their way to make the switch of the master of a package to julia 0.4 as late as possible.

 

From: [hidden email] [[hidden email]] On Behalf Of Iain Dunning
Sent: Monday, August 18, 2014 6:12 PM
To: [hidden email]
Subject: Re: [julia-stats] Re: Getting ready for Julia 0.3

 

An unsolicited thought on versioning:

 

DataFrames, for example, is on v0.5.7 right now. Something that seems sensible to me, right now at least is:

 

1. Release a new version v0.6.0

2. Create a release06 or julia03 branch on DataFrames.jl at this commit

3. First Julia 0.4 only release gets a new minor version v0.7.0

4. Any fixes on the old version go in the v0.6.x line.

 

Alternatively, keep the 0.5.x line as the Julia 0.3 line, make 0.6.x the Julia 0.4 line. Anyway, I think its something we should be making explicit to package maintainers, because I think that even pre 1.0 versions can have some signals encoded in the release numbers.

 

JuMP was easy to keep working on 0.2 and 0.3, relative to other packages, but there are a lot of goodies on 0.4 that are going to mean we will want to make a split much sooner...

 

Still, nothing needs to *break* on 0.3 which is the important thing, and we have the experience and tooling now to avoid that.

 

Exciting times!


On Monday, August 18, 2014 8:31:28 PM UTC-4, Simon Kornblith wrote:

On Monday, August 18, 2014 4:04:39 PM UTC-4, John Myles White wrote:

I think there are two questions here:

 

(1) Do breaking changes need to happen on 0.4 or can they happen on 0.3?

 

(2) How do we make sure that breaking changes won't affect users of 0.3?

 

Re. (1), I think we could do development against 0.3 for a while. I'm actually doing that right now. But we're going to want to target 0.4 as soon as 0.4 changes the indexing rules for arrays since DataArrays will need to sync up with that behavior. So we have to move to 0.4 at some point. I think it's easier to make that move sooner rather than later, but we could put it off for a while.

 

Re. (2), I don't see any way to have any point releases of master without using 0.4 as a way to discriminate between stable and dev version fo DataFrames. We could handle this by only providing point releases for 0.3, so that METADATA would never give you access to the devel state of DataFrames. That might be a reasonable thing to do to emphasize that DataFrames is in state of flux.

 

Regarding your last point about tolerances for bugs, I think part of the difficulty is that most people view a programming language as a tool they would employ rather than a community they would participate in. Even though Julia's open source, many people treat it like a commerical product that the developers should be selling to them, rather than a project that anyone can choose to participate in. This has become something I'm sadder and sadder about, since it's very different from working at Facebook, where people tend to assume that if some system's broken, they're the ones who should go fix it. ("Nothing is someone else's problem" is actually one of our internal mottos.)

 

Generally, I think Julia's ecosystem is far better in this regard than other open source projects I've worked on, which have a handful of regular contributors, a handful more occasional contributors, and >1 million users. Julia users are generally early adopters who know how to code well enough that picking up a new programming language isn't a big deal, and a substantial proportion (although not the majority) do actually contribute. I'm confident that we'll continue to attract new contributors in the future, but the contributor to user ratio is only going to go down from here.

 

In general, I think the problem with maintaining code for old releases is precisely that Julia is a community-driven project and most contributors use the latest master. People who are writing code in their spare time are not particularly inclined to spend that time coding things that 1) don't affect them and 2) will become obsolete when the next version is released. This is something that will resolve itself with time as the language stabilizes and it becomes easier to write code that works with both the last release and latest master. I'm hopeful most of the breaking changes will be over by the time 0.4 is released and it will be easier to maintain compatibility between 0.4 and 0.5, but we know that 0.4 will be a particularly difficult transition. I realize that this may detract from our user base, but for now, I don't really see a solution.

 

Simon

-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

 

-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

 

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

John Myles White
Ah, I misunderstood your point. I largely agree with this perspective, although it lacks the "everyone who's not a dev is using the same version" property that would make supporting 0.3 easier. I think that point is really important to keep in mind. Supporting the pre-release of 0.3 was so hard in large part because people weren't actively updating every day (or were doing so using Pkg.update, not Pkg.checkout).

I think the important distinction is whether you intend to make substantive changes or not. Distributions has a pretty solid interface that will probably be augmented over time, but not radically changed. DataFrames is at the other end of the spectrum.

So I don't think we need to force Distributions to split things between 0.3 and 0.4. But I do think it would be slightly better to do so to simplify supporting the 0.3 release.

 -- John

On Aug 20, 2014, at 10:15 AM, David Anthoff <[hidden email]> wrote:

I didn’t mean to suggest stuff should be back ported, I agree that would just be a waste of time. What I am suggesting is that packages that can be developed further without a dependency on new julia 0.4 features should have their master continue target julia 0.3 for as long as possible. DataFrames might not be one of those, but I am sure there are countless other packages where there really is no need at this point to make their active branch depend on julia 0.4. Maybe an example is Distributions.jl, couldn’t its master stay on julia 0.3 for quite a while, get new features for a couple of months before it starts to depend on julia 0.4? If it is not Distributions.jl, I’m sure there are other packages where this would be true. I read your original mail as suggesting “all packages in julia-stats should switch their master to 0.4 now”, and I would prefer to have the message be “if your package requires something in julia 0.4, switch, otherwise try to stay on julia 0.3 for a while”.
 
Cheers,
David
 
From: [hidden email] [[hidden email]] On Behalf Of John Myles White
Sent: Tuesday, August 19, 2014 11:47 AM
To: [hidden email]
Subject: Re: [julia-stats] Re: Getting ready for Julia 0.3
 
I broadly agree with Iain's suggestions. But I also disagree with some of your suggestions, David.
 
In particular, I think the response to, "how can I do X?", is simply "you can't do this yet. Wait for 0.4 in a few months."
 
The only way we can offer new functionality for the 0.3 release is if there's new people coming into the community who are willing to volunteer to handle backporting features to 0.3. Absent new people stepping up to do that work, I think it's a misuse of our resources to port features back to 0.3 -- especially because the features I'm interested in getting finished for 0.4 all interact with one another and can't be used in isolation. As such, trying to do backporting is like doubling the amount of work we have to do. If people want to volunteer to do that work, that would be great. But I don't think we can reasonably agree to do that work without a substantial influx of new developers, each dedicating a substantial amount of work time per week.
 
Given the constained resources we have, I think there are two tracks people are allowed to select into:
 
(1) End users, who don't do development work and receive non-bugfix changes on a 6-8 month schedule. Their problems are easier to debug if they're all going to be working with exactly one point release, not a gradually shifting master release. Much of what made debugging so hard in the last cycle was that 0.2 was clearly dead, but lots of people weren't keeping up with the dev branch by doing updates every day. So they reported problems that couldn't be reproduced without doing a huge amount of work. That's something we need to completely prevent in the future.
 
(2) Developers, who are expected to resolve any bugs they hit for themselves. The assumption is always that developers work with the bleeding edge of everything because they track changes on a daily basis and are subscribed to all of the repos they work on.
 
 -- John
 
On Aug 19, 2014, at 11:14 AM, David Anthoff <[hidden email]> wrote:


One vote for keeping the package masters on julia 0.3 for as long as possible.
 
There are really two issues: 1) obviously what really shouldn’t happen is that packages don’t work on 0.3 (i.e. what happened with 0.2), but my sense is that this can be achieved by packages maintainers being careful and keeping a frozen version that targets julia 0.3. But issue 2) is whether for users of julia 0.3 packages will see no improvements other than bug fixes until julia 0.4 will be released. I think if that were to happen it would be unfortunate. Things just start to feel “stale”, users will ask “how can I do X” and people will answer “use julia pre 0.4, because we implemented this in a package that targets a dev version” etc.
 
I would MUCH prefer that normal package development continues to target julia 0.3 as long as possible, so that as a user I don’t feel that I’m way behind the curve in a few months already. I think that would generally also add a great deal to make julia and its package eco system somewhat usable and stable to “normal” users.
 
I see that at some point this won’t work (e.g. the changes to indexing in 0.4 Miles mentioned), but I would suggest people go out of their way to make the switch of the master of a package to julia 0.4 as late as possible.
 
From: [hidden email] [[hidden email]] On Behalf Of Iain Dunning
Sent: Monday, August 18, 2014 6:12 PM
To: [hidden email]
Subject: Re: [julia-stats] Re: Getting ready for Julia 0.3
 
An unsolicited thought on versioning:
 
DataFrames, for example, is on v0.5.7 right now. Something that seems sensible to me, right now at least is:
 
1. Release a new version v0.6.0
2. Create a release06 or julia03 branch on DataFrames.jl at this commit
3. First Julia 0.4 only release gets a new minor version v0.7.0
4. Any fixes on the old version go in the v0.6.x line.
 
Alternatively, keep the 0.5.x line as the Julia 0.3 line, make 0.6.x the Julia 0.4 line. Anyway, I think its something we should be making explicit to package maintainers, because I think that even pre 1.0 versions can have some signals encoded in the release numbers.
 
JuMP was easy to keep working on 0.2 and 0.3, relative to other packages, but there are a lot of goodies on 0.4 that are going to mean we will want to make a split much sooner...
 
Still, nothing needs to *break* on 0.3 which is the important thing, and we have the experience and tooling now to avoid that.
 
Exciting times!

On Monday, August 18, 2014 8:31:28 PM UTC-4, Simon Kornblith wrote:
On Monday, August 18, 2014 4:04:39 PM UTC-4, John Myles White wrote:
I think there are two questions here:
 
(1) Do breaking changes need to happen on 0.4 or can they happen on 0.3?
 
(2) How do we make sure that breaking changes won't affect users of 0.3?
 
Re. (1), I think we could do development against 0.3 for a while. I'm actually doing that right now. But we're going to want to target 0.4 as soon as 0.4 changes the indexing rules for arrays since DataArrays will need to sync up with that behavior. So we have to move to 0.4 at some point. I think it's easier to make that move sooner rather than later, but we could put it off for a while.
 
Re. (2), I don't see any way to have any point releases of master without using 0.4 as a way to discriminate between stable and dev version fo DataFrames. We could handle this by only providing point releases for 0.3, so that METADATA would never give you access to the devel state of DataFrames. That might be a reasonable thing to do to emphasize that DataFrames is in state of flux.
 
Regarding your last point about tolerances for bugs, I think part of the difficulty is that most people view a programming language as a tool they would employ rather than a community they would participate in. Even though Julia's open source, many people treat it like a commerical product that the developers should be selling to them, rather than a project that anyone can choose to participate in. This has become something I'm sadder and sadder about, since it's very different from working at Facebook, where people tend to assume that if some system's broken, they're the ones who should go fix it. ("Nothing is someone else's problem" is actually one of our internal mottos.)
 
Generally, I think Julia's ecosystem is far better in this regard than other open source projects I've worked on, which have a handful of regular contributors, a handful more occasional contributors, and >1 million users. Julia users are generally early adopters who know how to code well enough that picking up a new programming language isn't a big deal, and a substantial proportion (although not the majority) do actually contribute. I'm confident that we'll continue to attract new contributors in the future, but the contributor to user ratio is only going to go down from here.
 
In general, I think the problem with maintaining code for old releases is precisely that Julia is a community-driven project and most contributors use the latest master. People who are writing code in their spare time are not particularly inclined to spend that time coding things that 1) don't affect them and 2) will become obsolete when the next version is released. This is something that will resolve itself with time as the language stabilizes and it becomes easier to write code that works with both the last release and latest master. I'm hopeful most of the breaking changes will be over by the time 0.4 is released and it will be easier to maintain compatibility between 0.4 and 0.5, but we know that 0.4 will be a particularly difficult transition. I realize that this may detract from our user base, but for now, I don't really see a solution.
 
Simon
-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
 
-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
 
-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Getting ready for Julia 0.3

Cameron McBride
In reply to this post by David Anthoff
well said, David.  This is exactly the point I was trying to make as well. 

But I also agree with the follow up responses, and perhaps the point is too generic too early.  Naturally, these are manpower limited and due a number of new 0.4 features, julia might still be too young to make such a focus a reality.  That certainly seems the case with DataFrames at least. 

Cameron


On Wed, Aug 20, 2014 at 1:15 PM, David Anthoff <[hidden email]> wrote:

I didn’t mean to suggest stuff should be back ported, I agree that would just be a waste of time. What I am suggesting is that packages that can be developed further without a dependency on new julia 0.4 features should have their master continue target julia 0.3 for as long as possible. DataFrames might not be one of those, but I am sure there are countless other packages where there really is no need at this point to make their active branch depend on julia 0.4. Maybe an example is Distributions.jl, couldn’t its master stay on julia 0.3 for quite a while, get new features for a couple of months before it starts to depend on julia 0.4? If it is not Distributions.jl, I’m sure there are other packages where this would be true. I read your original mail as suggesting “all packages in julia-stats should switch their master to 0.4 now”, and I would prefer to have the message be “if your package requires something in julia 0.4, switch, otherwise try to stay on julia 0.3 for a while”.

 

Cheers,

David

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of John Myles White
Sent: Tuesday, August 19, 2014 11:47 AM


To: [hidden email]
Subject: Re: [julia-stats] Re: Getting ready for Julia 0.3

 

I broadly agree with Iain's suggestions. But I also disagree with some of your suggestions, David.

 

In particular, I think the response to, "how can I do X?", is simply "you can't do this yet. Wait for 0.4 in a few months."

 

The only way we can offer new functionality for the 0.3 release is if there's new people coming into the community who are willing to volunteer to handle backporting features to 0.3. Absent new people stepping up to do that work, I think it's a misuse of our resources to port features back to 0.3 -- especially because the features I'm interested in getting finished for 0.4 all interact with one another and can't be used in isolation. As such, trying to do backporting is like doubling the amount of work we have to do. If people want to volunteer to do that work, that would be great. But I don't think we can reasonably agree to do that work without a substantial influx of new developers, each dedicating a substantial amount of work time per week.

 

Given the constained resources we have, I think there are two tracks people are allowed to select into:

 

(1) End users, who don't do development work and receive non-bugfix changes on a 6-8 month schedule. Their problems are easier to debug if they're all going to be working with exactly one point release, not a gradually shifting master release. Much of what made debugging so hard in the last cycle was that 0.2 was clearly dead, but lots of people weren't keeping up with the dev branch by doing updates every day. So they reported problems that couldn't be reproduced without doing a huge amount of work. That's something we need to completely prevent in the future.

 

(2) Developers, who are expected to resolve any bugs they hit for themselves. The assumption is always that developers work with the bleeding edge of everything because they track changes on a daily basis and are subscribed to all of the repos they work on.

 

 -- John

 

On Aug 19, 2014, at 11:14 AM, David Anthoff <[hidden email]> wrote:



One vote for keeping the package masters on julia 0.3 for as long as possible.

 

There are really two issues: 1) obviously what really shouldn’t happen is that packages don’t work on 0.3 (i.e. what happened with 0.2), but my sense is that this can be achieved by packages maintainers being careful and keeping a frozen version that targets julia 0.3. But issue 2) is whether for users of julia 0.3 packages will see no improvements other than bug fixes until julia 0.4 will be released. I think if that were to happen it would be unfortunate. Things just start to feel “stale”, users will ask “how can I do X” and people will answer “use julia pre 0.4, because we implemented this in a package that targets a dev version” etc.

 

I would MUCH prefer that normal package development continues to target julia 0.3 as long as possible, so that as a user I don’t feel that I’m way behind the curve in a few months already. I think that would generally also add a great deal to make julia and its package eco system somewhat usable and stable to “normal” users.

 

I see that at some point this won’t work (e.g. the changes to indexing in 0.4 Miles mentioned), but I would suggest people go out of their way to make the switch of the master of a package to julia 0.4 as late as possible.

 

From: [hidden email] [[hidden email]] On Behalf Of Iain Dunning
Sent: Monday, August 18, 2014 6:12 PM
To: [hidden email]
Subject: Re: [julia-stats] Re: Getting ready for Julia 0.3

 

An unsolicited thought on versioning:

 

DataFrames, for example, is on v0.5.7 right now. Something that seems sensible to me, right now at least is:

 

1. Release a new version v0.6.0

2. Create a release06 or julia03 branch on DataFrames.jl at this commit

3. First Julia 0.4 only release gets a new minor version v0.7.0

4. Any fixes on the old version go in the v0.6.x line.

 

Alternatively, keep the 0.5.x line as the Julia 0.3 line, make 0.6.x the Julia 0.4 line. Anyway, I think its something we should be making explicit to package maintainers, because I think that even pre 1.0 versions can have some signals encoded in the release numbers.

 

JuMP was easy to keep working on 0.2 and 0.3, relative to other packages, but there are a lot of goodies on 0.4 that are going to mean we will want to make a split much sooner...

 

Still, nothing needs to *break* on 0.3 which is the important thing, and we have the experience and tooling now to avoid that.

 

Exciting times!


On Monday, August 18, 2014 8:31:28 PM UTC-4, Simon Kornblith wrote:

On Monday, August 18, 2014 4:04:39 PM UTC-4, John Myles White wrote:

I think there are two questions here:

 

(1) Do breaking changes need to happen on 0.4 or can they happen on 0.3?

 

(2) How do we make sure that breaking changes won't affect users of 0.3?

 

Re. (1), I think we could do development against 0.3 for a while. I'm actually doing that right now. But we're going to want to target 0.4 as soon as 0.4 changes the indexing rules for arrays since DataArrays will need to sync up with that behavior. So we have to move to 0.4 at some point. I think it's easier to make that move sooner rather than later, but we could put it off for a while.

 

Re. (2), I don't see any way to have any point releases of master without using 0.4 as a way to discriminate between stable and dev version fo DataFrames. We could handle this by only providing point releases for 0.3, so that METADATA would never give you access to the devel state of DataFrames. That might be a reasonable thing to do to emphasize that DataFrames is in state of flux.

 

Regarding your last point about tolerances for bugs, I think part of the difficulty is that most people view a programming language as a tool they would employ rather than a community they would participate in. Even though Julia's open source, many people treat it like a commerical product that the developers should be selling to them, rather than a project that anyone can choose to participate in. This has become something I'm sadder and sadder about, since it's very different from working at Facebook, where people tend to assume that if some system's broken, they're the ones who should go fix it. ("Nothing is someone else's problem" is actually one of our internal mottos.)

 

Generally, I think Julia's ecosystem is far better in this regard than other open source projects I've worked on, which have a handful of regular contributors, a handful more occasional contributors, and >1 million users. Julia users are generally early adopters who know how to code well enough that picking up a new programming language isn't a big deal, and a substantial proportion (although not the majority) do actually contribute. I'm confident that we'll continue to attract new contributors in the future, but the contributor to user ratio is only going to go down from here.

 

In general, I think the problem with maintaining code for old releases is precisely that Julia is a community-driven project and most contributors use the latest master. People who are writing code in their spare time are not particularly inclined to spend that time coding things that 1) don't affect them and 2) will become obsolete when the next version is released. This is something that will resolve itself with time as the language stabilizes and it becomes easier to write code that works with both the last release and latest master. I'm hopeful most of the breaking changes will be over by the time 0.4 is released and it will be easier to maintain compatibility between 0.4 and 0.5, but we know that 0.4 will be a particularly difficult transition. I realize that this may detract from our user base, but for now, I don't really see a solution.

 

Simon

-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

 

-- 
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

 

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "julia-stats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
12