Prepare pijul-0.7.0

Development
1

I think now is a good time to consider a new release for pijul.

ChangeLog

If you find something is missing, please feel free to tell. The goal is to have an as useful as possible ChangeLog for end-users.

Features

  • pijul status: print the list of staging changes
  • .ignore and .pijul/local/ignore files can be used to filter the pijul status output.

Enhancement

  • Improve test coverage

Bug Fixes

  • Fixing a stack overflow in pijul apply

Dependencies

  • bitflags: 0.8 → 0.9
  • hyper-rustly: 0.5 → 0.6

Pending Features

If a pending feature is missing here, feel free to tell.

  • show-dependencies command: do we want it in this release or in the next? (@lthms)
  • the global configuration should use the app_dirs crate so that it goes in a good, platform-appropriate place (@joeneeman)

Blocking Issue

I’ve reported two issues which should be taken care of before releasing, IMO.

Any feedback on that matter?

2

Are you talking about my patch here? Because that wasn’t an enhancement relative to the last release: I was just undoing a (presumably unintended) change.

Also, there’s one change I’d like to make before the next release, but haven’t had time: the global configuration should use the app_dirs crate so that it goes in a good, platform-appropriate place.

3

I’ve edited the first post in consequence, thanks for your feedback!

Should I consider it a bug fix? Or has it been introduced after the 0.6.0 release and therefore shouldn’t appear in the ChangeLog?

4

I think it appeared after 0.6.0.

1 Like
5

One blocking issue has been fixed by @pmeunier. Thanks a lot!

6

Just fixed the other one :triumph:

1 Like
7

There are still several conflicts @laumann has fixed.

8

As for as I know, all pending issues have been fixed. I will push one last time a patch to add my show-dependencies command and we will wait for @joeneeman to finish its own item and I think we will be good. Once done, we will just have to update the ChangeLog before releasing.

Do not hesitate to test the latest pijul as much as possible, @all!

9

I just pushed my patch. I’m going to modify the changelog next.

1 Like
10

Thanks a lot, @joeneeman! I think we will be ready for releasing this weekend if that suits the pijul team. I will try to push my own patch so that either @pmeunier or @flobec can merge them along with yours.

11

Hi guys! I’m sorry, but I had to make lots of changes in the Nest recently, mostly for stability problems. I’ve not been able to do it all as fast as I first imagined.

Summary of the changes to the Nest in the last week:

  • no more pending patches, these were really fat on disk. They might come back in the future.
  • massive refactoring: several modules were getting fat (> 3000 lines). The situation is now back under control, but I had to re-debug a number of things (such as oauth).
  • repositories got an “admin” page. You can give extra permissions to other users. The UI is not great. Also, remember that all repos on the Nest are public anyway, and there’s no way yet to create a private repository.
  • after a testing period, webhooks are now available for all repositories.
  • the Pijul IRC bot is now public.

Now that the Nest is back on its feet, I’d like to ask you guys to check if you want any other patch in. Else, I’ll upload 0.7 to crates.io, and build a windows version, by tomorrow (Thursday) night.

12

IMO, before releasing, we need to:

  1. add pijul show-dependencies
  2. add app-dir’s patch crate by @joeneeman
  3. add Cargo.lock to the include directive of Cargo.toml (to be sure cargo install pijul is reproductible)
1 Like
14

I think we should release the current state of master as 0.7.0 (modulo writing a changelog / announcement)

15

I can help for that. The only thing I could add is you have introduced the wrong version of my show-dependencies command. It is not a big deal however: I will try to submit the diff as an additional patch for the next release.

16

sorry about that and thanks for fixing it.

17

So, should I release?

18

I’d say yes, unless lthms wants to wait for something (the version needs to be bumped, of course)

19

Maybe this would be a good time to add documentation. I’ll try to do it and release later today.

20

I think we are good to go. Can you create a branch when it is done, so we can backport potential fixes?

21

Alright, some work was needed, I took the opportunity to document libpijul better, and to do a general cleanup.

I also switched to error-chain for error handling, instead of doing the same thing manually.

2 Likes