Ihor Radchenko writes:
> I think that upper limit for bugfix release frequency is slightly in
> odds with the previous
>
> Org development is the work of volunteers, and we cannot promise to
> follow a release schedule.
You're right -- I've rephrase it like so:
Security fixes trigger
Bastien Guerry writes:
> Security fixes trigger an immediate bugfix release. Other important
> fixes should be accumulated for more than one week and for less than
> two weeks before a bugfix release.
>
> It's important to allow immediate release for security fixes only, and
> to let the du
Ihor Radchenko writes:
> What do you think about the attached patch?
I like the idea. I've pushed a slightly different version:
https://git.sr.ht/~bzg/worg/commit/45d6c45759
Security fixes trigger an immediate bugfix release. Other important
fixes should be accumulated for more than one we
On Sun, 10 Dec 2023 13:24:30 +0100 Ihor Radchenko wrote ---
> Doing the releases too frequently will increase a chance of such bugs
> crawling into ELPA releases. So, there should be at least a minimal
> waiting period to get a chance to handle such problems.
Thank you for explain
Matt writes:
> Not part of the patch, but part of the context: "you shoud *NOT*" -> "you
> should *NOT*" (missing the 'l') Already fixed and pushed
> (https://git.sr.ht/~bzg/worg/commit/a11b256086d567d0894d337b548ec13049a8731b)
Thanks!
> Regarding the patch, it seems reasonable.
>
> Potent
On Sun, 10 Dec 2023 12:27:01 +0100 Ihor Radchenko wrote ---
> What do you think about the attached patch?
Not part of the patch, but part of the context: "you shoud *NOT*" -> "you
should *NOT*" (missing the 'l') Already fixed and pushed
(https://git.sr.ht/~bzg/worg/commit/a11b25608
Even though we do not follow release schedule, I think that it is worth
adding a note about bugfix releases - there is really no reason to delay
them most of the time, as soon as we have new commits on bugfix.
What do you think about the attached patch?
>From e27e05c48a8f36e3c322f0b5a4881d63
