and some other things that @Chris Simpkins added
maybe fork to new topic to discuss a release?
moved everything to a new topic
current version is 0.2.1, we can release 0.3.0 I guess with all this stuff :)
yeah, I started looking at trying to make something to query github.com directly to get the PR's in a commit range. But I don't think I'll have anything I'm happy with in the short term.
(I was briefly considering saying "oh lets hold on until I get this done", but I've abandoned that optimism now)
should we check in with @simulacrum before doing a release?
/me wishes we had a test suite.
actually I guess it wouldn't be that hard to make a test suite, if we're willing to use
--end for all the tests, and just cross our finges that the behavior without
--end does not break.
I think making a release is a good idea, can always bugfix in .1 or so.
I have not reviewed changelog or anything like that though :)
actually I guess it wouldn't be that hard to make a test suite,
I've been thinking through how to approach this. The commit level rustc caches expire at the 167 day mark so the tests covering this part of the source would need to be updated periodically.
hmm. that is a good point.
we might at least be able to make the update process relatively painless, by using rustversion and
Do you have a suggestion about how to refactor the source to best support tests? I discussed moving most of the source that currently lives in main.rs into a library and adding unit/integration tests with Santiago last week. He supports this and Mark indicated that he is deferring the review to Santiago due to other time commitments.
The error handling PR is a first step in that direction. It only refactors custom errors out of main.rs and doesn't address the testing issue. At the moment, the git functionality and the least_satisfying nightly/commit testing approach live outside of main.rs. We can move everything else from the
run() function up into a lib.rs at this stage or use a more modular approach, then begin the work on the tests.
btw, I can release but we do not have a CHANGELOG
I think is worth adding that
can't do that today if someone can meanwhile would be great otherwise I can make it tomorrow
np, I can add one now
@Santiago Pastorino This will be v0.3.0?
thanks when you do I can merge and release
I don't see any tagged releases for previous versions. It looks like the Cargo.toml change history has commits for v0.2.1 and v0.2.0. I will see if I can track down changes that happened between those releases and add them too
seems like previous versions are not tagged :(
we could tag backwards I guess
have tagged previous versions
and releasing 0.3.0 ...