5 ms·

This is the part that concerns me. Generally, I think of code tightening in on a release, which major swings early in the processes and minor tweaks later. Whil

This is the part that concerns me. Generally, I think of code tightening in on a release, which major swings early in the processes and minor tweaks later. While I all for everything that happened in this change, I wonder if a 0.2 (or even 0.9) would have been appropriate first. Version x.0 in open source software implies "this is ready for production" (as opposed to commercial software, where it seems to mean "let the beta test really commence). (I just noticed it is at 1.0.2 now. I think I'm going to have to give this a couple weeks before I upgrade any of my projects.)

j-kidd 14y ago
Look out for the change to the Request constructor that makes `url` no longer the first parameter. Rather poor backward compatibility there.
- sethish 14y ago
  It's a major revision number change, that's the only time to do such a major api change.
  - j-kidd 14y ago
    While your point is valid, I didn't expect this to happen with requests. Just two weeks ago, I was telling my colleague that requests is such a nice library, we have nothing to worry about when installing a new version. Simply grab the latest! Then 1.0 happens. I have now moved requests to the "thoroughly test before upgrade" pile.
    - kenneth_reitz 14y ago
      This is what major version numbers are for.
      - SoftwareMaven 14y ago
        It's an interesting challenge in the open source world to deal with. In closed source software, having x.0 break things us understandable. We generally never see all the effort between x.0 and (x+1).0. In open source, it's harder because all of that is open, which means there is a conflict between x.0 means "release" and x.0 means "development is just beginning. It probably should mean the latter. But then having a big "It's 1.0 and fabulous!" blog post is the wrong thing to do. It probably should have been "It's 1.0; be careful!" I don't see how you can have it both ways. Linus took care of that with odd/even versioning, but I think you need a huge project for people to pay enough attention to understand unless it became a de facto standard (which it hasn't in over a decade, so it's unlikely to). (BTW, I am very grateful for the work you've put into this. Requests is truly a model API. My comments are much more meta about versioning and open source in general (using this project as an example) and should in no way be construed as saying I think you are doing something wrong.)
brown9-2 14y ago
Version x.0 in open source software implies "this is ready for production" I've never really had this impression before. Do you think people would have been holding off on using a library like this because it was at 0.14 before? I'm curious where this impression comes from.
- SoftwareMaven 14y ago
  No, but I think people absolutely expect version 1.0 to be more stable than 0.14. The impression started with the linux kernel many years ago and has included many other pieces of software since. Versions either seem to mean "something changed" or "some set of features is ready". When you make a jump from 0.13 to 0.14, it is safe to assume the former. 0.14 to 1.0 tends to imply the latter.

j-kidd 14y ago

Look out for the change to the Request constructor that makes `url` no longer the first parameter. Rather poor backward compatibility there.

sethish 14y ago
It's a major revision number change, that's the only time to do such a major api change.
- j-kidd 14y ago
  While your point is valid, I didn't expect this to happen with requests. Just two weeks ago, I was telling my colleague that requests is such a nice library, we have nothing to worry about when installing a new version. Simply grab the latest! Then 1.0 happens. I have now moved requests to the "thoroughly test before upgrade" pile.
  - kenneth_reitz 14y ago
    This is what major version numbers are for.
    - SoftwareMaven 14y ago
      It's an interesting challenge in the open source world to deal with. In closed source software, having x.0 break things us understandable. We generally never see all the effort between x.0 and (x+1).0. In open source, it's harder because all of that is open, which means there is a conflict between x.0 means "release" and x.0 means "development is just beginning. It probably should mean the latter. But then having a big "It's 1.0 and fabulous!" blog post is the wrong thing to do. It probably should have been "It's 1.0; be careful!" I don't see how you can have it both ways. Linus took care of that with odd/even versioning, but I think you need a huge project for people to pay enough attention to understand unless it became a de facto standard (which it hasn't in over a decade, so it's unlikely to). (BTW, I am very grateful for the work you've put into this. Requests is truly a model API. My comments are much more meta about versioning and open source in general (using this project as an example) and should in no way be construed as saying I think you are doing something wrong.)

brown9-2 14y ago

Version x.0 in open source software implies "this is ready for production" I've never really had this impression before. Do you think people would have been holding off on using a library like this because it was at 0.14 before? I'm curious where this impression comes from.

SoftwareMaven 14y ago
No, but I think people absolutely expect version 1.0 to be more stable than 0.14. The impression started with the linux kernel many years ago and has included many other pieces of software since. Versions either seem to mean "something changed" or "some set of features is ready". When you make a jump from 0.13 to 0.14, it is safe to assume the former. 0.14 to 1.0 tends to imply the latter.