Closed king-11 closed 2 weeks ago
If the subsequent versions didn't break our usage, we might want to expand the version range to >= x.y, <= 0.52
for max compatibility.
But for simple version bumps, #178 should resolve this and others.
According to the passing CI jobs in https://github.com/colored-rs/colored/pull/183 we can actually expand the version range to >= 0.48, <= 0.59
.
That sounds great already were prepared for it any reason for withholding it?
any reason for withholding it?
I just merged in #178 so #183 was just created, so it's a bit too recent to be considered withheld :laughing: I'd accept a PR to apply the version range I'm recommending instead of the "simple" version bump in #183.
ouch sorry for not taking a look at date it was created just getting a range PR ready thanks for quick response :)
Closing the issue as PR is merged but this would require a new release as well for downstream resources to consume.
@spenserblack would it be possible to have a minor version release or is there some cycle that is followed which would include this?
Collaborators don't always have full access to do everything necessary for a new release (e.g. publishing to package repositories), so I generally avoid creating releases when I'm just a collaborator. For example, I wouldn't make a new release myself in onefetch.
But, luckily, the publish workflow should take care of everything, so I think I can make a release if nobody else is available. I just need to double-check the changes since the last release to know which version to bump to.
Please don't hesitate to remind me if I don't make a new release next month :laughing:
Sounds good thanks a lot :)
windows-sys had a release after 8 months which covers a lot of fixes and changes now they are regularly updating as well.
since coloured relies on 0.48 its pulling that while most other crates have updated to 0.52 atleast causing duplicate dependencies.