-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prep for a 1.5 release -- what else do we need? #657
Comments
Well, for one there's a PR from @pkoppstein I need to finish merging... |
And, of course, I hope you're all having very happy holidays. Don't spend much time thinking about jq 1.5. |
I think it's ready for rc1. |
I seem constantly to be defining:
Less often but nicely compact:
A random number generator would be very nice as well :-) |
On Thu, Jan 01, 2015 at 10:26:43PM -0800, pkoppstein wrote:
Yes, that's a good one. We already have Though
Interesting. Could we do something like:
then you could say:
Not every idiom needs a builtin, but many do! |
A little oblique.
Yes, that would be handy, but then again, (1) it doesn't do much more than |
Yes, I also thought of Another possible name for I've been writing a lot of |
@nicowilliams wrote:
Another thing I don't like so much about
As for length/1 -- although I could easily get used to it, there's something to be said for choosing one name for arrays (length/0) and another for streams (count/1). It helps keep the two concepts (arrays and streams) well-separated psychologically; and linguistically, we count sheep entering a pen, as opposed to measuring the length of the pen. |
OK, fair point. |
Regarding count/1 and count/2, I'd like to propose an enhancement to count/2 as follows:
E.g. In other words, a little more mileage. |
There is a tiny error in the NEWS file, which seems too small to warrant an entire "Issue" unto itself, but which maybe could be corrected even before 1.5 is released: |
I just want |
@nicowilliams gets back from a month of travel tomorrow. Let's give him a few days to catch up, then put out 1.5rc2. No later than next Saturday! Then the real 1.5 release no later than 2 weeks after rc2 unless we discover major issues that take longer to fix. |
We should do a 1.5rc2 release ASAP. I think 8295baf is a good candidate. I can build executables for Linux and Windows, and can probably build for OS X or get Homebrew to do it. I'm sure so can @dtolnay and @wtlangford. I wonder if we could get Travis-CI to build Windows executables... It would really be best to let Travis do all the building of release executables. |
OK, I'll do the builds later tonight (dinner time now). |
Thanks Nico! |
Habemus 1.5rc2. (Though I need to re-update the executables and tarballs after pushing a fix for #870, but none of them should change at all.) |
What does the development process look like in between 1.5rc2 and 1.5? There are some bugs I want to fix that should not be in 1.5 at this point. I propose creating a release branch "release/jq-1.5" starting at the commit currently tagged as the RC. Critical fixes that need to be in 1.5 can be done on the release branch, and less critical things can be done on master for 1.6. We merge the release branch into master as needed. At the time of the 1.5 release, the head of the release branch is tagged as jq-1.5 and the release branch is deleted. In the ideal case (no critical changes required), the release branch never moves and jq-1.5rc2 and jq-1.5 are the same commit. |
I was hoping we could keep linear development. I agree that if we need to port anything from master into 1.5 and if master has things we don't want in 1.5, then we should create a 1.5 branch. Since you have such commits, I've pushed a jq-1.5-branch branch that we can use to cherry-pick commits onto. |
Also, we should push to master first, then cherry-pick onto jq-1.5-branch as needed. |
The person pushing to master should decide whether to also cherry-pick onto and push to jq-1.5-branch. |
Okay, sounds good. |
Tomorrow I'll edit gh-pages to point to the 1.5rc2 release. |
@dtolnay Do please review the 1.5rc2 release text and add anything I may have missed. |
At this point we are good to go for 1.5, right? @nicowilliams do you have time and energy this week or this weekend to do the release? |
I'll have time and energy late next week and weekend, and hopefully a bit this Saturday. I think I still need to check on the module system parts for @joelpurra. |
Per this comment I think that is okay to do next milestone. The existing PR is a little too scary to put in at the last second. |
So, the only part of @joelpurra's patches that I think we should consider for 1.5 at this point is the patch to search for a That means we need only consider whether to fix the bugs found by @DRMacIver using AFL. Otherwise I can make a release this weekend. |
The scariest one you already fixed and cherry-picked across (#896). I have a PR waiting for code review that fixes 2 more, and there is 1 left to fix. I think all 3 remaining ones should wait for 1.6. |
Yeah, speaking of which, I need to review it! |
Besides the issues and PRs marked for 1.5, what else must we add?
I'd really like to have some built-in modules that can be
import
ed but which are compiled into the executable. In particular I'd like to have a) all of the normal jq builtins available as a module named "jq" that can be imported (and even versioned!) by calling modules, and b) builtin modules to start putting new builtins into and stop polluting the global namespace.Ideally a program could even ask not to get the <1.4 pollution, except for very few, very special builtins, namely: all the byte-coded ones, like
empty
,not
,path
, andrange/2
, all the private C-coded builtins, and all the ones thatparser.y
codes or depends on, likerecurse
.But I don't think I'll have time to put that together for 1.5. Instead I'd like to fix all the outstanding issues and make 1.6 a vehicle for module/namespace awesomeness.
So, what must still be done for 1.5?
The text was updated successfully, but these errors were encountered: