some months ago, a bad upstream tag changed node-markdown-it version to 22.2.3 instead of 10.0.0. So I'd like to change node-markdown-it version
into 1:13.0.1
Quoting Yadd (2022-08-19 10:21:17)
some months ago, a bad upstream tag changed node-markdown-it version to
22.2.3 instead of 10.0.0. So I'd like to change node-markdown-it version
into 1:13.0.1
Since upstream is already at 10, is it unlikely that they will reach 22
in the foreseeable future?
What I am getting at is that introducing an epoch is a pain *forever*
(all dependent packages must then *forever* remember to add "1:" prefix) wheread converting the accidental too-high major version into
pseudo-epoch "22.really." will last only until upstream catches up.
Hi,
On Fri, 19 Aug 2022, at 16:37, Jonas Smedegaard wrote:
Quoting Yadd (2022-08-19 10:21:17)
some months ago, a bad upstream tag changed node-markdown-it version to >> 22.2.3 instead of 10.0.0. So I'd like to change node-markdown-it version >> into 1:13.0.1
Since upstream is already at 10, is it unlikely that they will reach 22
in the foreseeable future?
What I am getting at is that introducing an epoch is a pain *forever*
(all dependent packages must then *forever* remember to add "1:" prefix) wheread converting the accidental too-high major version into
pseudo-epoch "22.really." will last only until upstream catches up.
I agree, adding an epoch in this package doesn’t seem appropriate or necessary.
I agree, adding an epoch in this package doesn’t seem appropriate or necessary.
JTFR - Upstream released 12.0.4 in 2020, and they have reached 13.0.1
_now_ (after two years)
Going by previous releases, the delta between one major release is
atleast an year.
And so reaching to 22.2.3 will take a very long time as well, if not _forever_
and that would mean keeping up with +really for several years. I do
not think tagging this along with really is much better than adding in an epoch.
(I personally find the former a bit more ugly for my taste)
Hi,
On Fri, 19 Aug 2022, at 17:45, Nilesh Patra wrote:
I agree, adding an epoch in this package doesn’t seem
appropriate or necessary.
JTFR - Upstream released 12.0.4 in 2020, and they have reached
13.0.1
_now_ (after two years)
Going by previous releases, the delta between one major release is
atleast an year.
And so reaching to 22.2.3 will take a very long time as well, if
not _forever_
and that would mean keeping up with +really for several years. I do
not think tagging this along with really is much better than adding
in an epoch.
(I personally find the former a bit more ugly for my taste)
As Jonas said, an epoch cannot be undone, +really can, regardless
when this is going to happen. Both are ugly solutions, but an epoch
is also evil, unlike +really 🙂
Hi,
On Fri, 19 Aug 2022, at 17:45, Nilesh Patra wrote:
I agree, adding an epoch in this package doesn’t seem appropriate or necessary.
JTFR - Upstream released 12.0.4 in 2020, and they have reached 13.0.1 _now_ (after two years)
Going by previous releases, the delta between one major release is
atleast an year.
And so reaching to 22.2.3 will take a very long time as well, if not _forever_
and that would mean keeping up with +really for several years. I do
not think tagging this along with really is much better than adding in an epoch.
(I personally find the former a bit more ugly for my taste)
As Jonas said, an epoch cannot be undone, +really can, regardless when this is going to happen.
Both are ugly solutions, but an epoch is also evil, unlike +really 🙂
As Jonas said, an epoch cannot be undone, +really can, regardless when this is going to happen.
I think ignoring when it happens is not the right way to see it. Even if we assume that
upstream is going to work on this with the same effort, we will still end up waiting
for a _decade_ for the +really to go away.
Is tagging this along for so many years really is more worthy than an epoch? Note that the package might even go stale in such a long time, thought.
Are we going to deny every epoch request or this is going to be subjective?
On Fri, Aug 19, 2022 at 04:43:17PM +0200, Andrej Shadura wrote:
Hi,
On Fri, 19 Aug 2022, at 16:37, Jonas Smedegaard wrote:
Quoting Yadd (2022-08-19 10:21:17)
some months ago, a bad upstream tag changed node-markdown-it version to >> 22.2.3 instead of 10.0.0. So I'd like to change node-markdown-it version
into 1:13.0.1
Since upstream is already at 10, is it unlikely that they will reach 22 in the foreseeable future?
What I am getting at is that introducing an epoch is a pain *forever* (all dependent packages must then *forever* remember to add "1:" prefix) wheread converting the accidental too-high major version into pseudo-epoch "22.really." will last only until upstream catches up.
I agree, adding an epoch in this package doesn’t seem appropriate or necessary.
JTFR - Upstream released 12.0.4 in 2020, and they have reached 13.0.1 _now_ (after two years)
Going by previous releases, the delta between one major release is atleast an year.
And so reaching to 22.2.3 will take a very long time as well, if not _forever_
and that would mean keeping up with +really for several years. I do
not think tagging this along with really is much better than adding in an epoch.
(I personally find the former a bit more ugly for my taste)
The only reverse-dependency of this package is "node-prosemirror-markdown" and so
it would not be too much work if an epoch is introduced.
Is tagging this along for so many years really is more worthy than an epoch?
Epochs cause problems, [...]
As Jonas said, an epoch cannot be undone, +really can, regardless when this is going to happen. Both are ugly solutions, but an epoch is also evil, unlike +really 🙂
On Fri, Aug 19, 2022 at 09:51:14PM +0530, Nilesh Patra wrote:
As Jonas said, an epoch cannot be undone, +really can, regardless when this is going to happen.
I think ignoring when it happens is not the right way to see it. Even if we assume that
upstream is going to work on this with the same effort, we will still end up waiting
for a _decade_ for the +really to go away.
Is tagging this along for so many years really is more worthy than an epoch?
Note that the package might even go stale in such a long time, thought.
BTW, Jonas also said, "is it unlikely that they will reach 22
in the foreseeable future?"
On Fri, Aug 19, 2022 at 10:00:58PM +0530, Nilesh Patra wrote:
On Fri, Aug 19, 2022 at 09:51:14PM +0530, Nilesh Patra wrote:
As Jonas said, an epoch cannot be undone, +really can, regardless when this is going to happen.
I think ignoring when it happens is not the right way to see it. Even if we assume that
upstream is going to work on this with the same effort, we will still end up waiting
for a _decade_ for the +really to go away.
Is tagging this along for so many years really is more worthy than an epoch?
Note that the package might even go stale in such a long time, thought.
BTW, Jonas also said, "is it unlikely that they will reach 22
in the foreseeable future?"
Did you consider asking them to advance to 22+ with their next release? Afterall, I read it that way that it that there was some issue with that 22 version, and they might have also interest in putting that into the past?
The standard one is that people use them to revert an upload.Epochs cause problems, [...]which are? (I agree they are ugly and should often be avoided, but I don't see any unsolved problems with them, which is why I'm asking.)
But, epochs aren't used in the upstream tarball filename, so you then
easily get a conflict between the old and the new one.
On Fri, Aug 19, 2022 at 06:00:44PM +0100, Simon McVittie wrote:
Epochs cause problems, [...]
which are? (I agree they are ugly and should often be avoided, but I don't see any unsolved problems with them, which is why I'm asking.)
On Sat, Aug 20, 2022 at 03:29:59PM +0000, Stefano Rivera wrote:
but I don'tEpochs cause problems, [...]which are? (I agree they are ugly and should often be avoided,
see any unsolved problems with them, which is why I'm asking.)The standard one is that people use them to revert an upload.
ok, I agree that's bad. (but not the case here.)
But, epochs aren't used in the upstream tarball filename, so you
then
easily get a conflict between the old and the new one.
I'd replace 'easily' with 'theoretically in rare cases' but I can see
how
this is a valid point, sometimes.
On Fri, 19 Aug 2022 at 21:36:24 +0530, Pirate Praveen wrote:
Are we going to deny every epoch request or this is going to be
subjective?
If there was a correct objective rule for what to do, we'd be applying
that rule mechanically, not asking our fellow developers for advice.
Epochs cause problems, but sometimes the alternatives are worse.
Deciding
which is the least-bad option is inherently a subjective question and
you
are not going to get an objective answer to it.
I do not have a strong opinion either way on this particular situation without knowing where 22.2.3 came from. As a way to mitigate this sort
of thing in future, I'd suggest that maintainers/sponsors should
confirm
whether upstreams were intentionally doing a multi-version jump like
that one before uploading the new version.
smcv
On ശ, ഓഗ 20, 2022 at 3:53 വൈകു, Holger Levsen <holger@layer-acht.org> wrote:
On Sat, Aug 20, 2022 at 03:29:59PM +0000, Stefano Rivera wrote:
but I don'tEpochs cause problems, [...]which are? (I agree they are ugly and should often be avoided,
see any unsolved problems with them, which is why I'm asking.)The standard one is that people use them to revert an upload.
ok, I agree that's bad. (but not the case here.)
But, epochs aren't used in the upstream tarball filename, so you
then
easily get a conflict between the old and the new one.
I'd replace 'easily' with 'theoretically in rare cases' but I can see
how
this is a valid point, sometimes.
I think the only real consequence for this is a dak reject which can be fixed by a new upload with +debian suffix.
Say when upstream again release 22.3 version, 1:22.3 orig.tar will have
a different checksum from 22.3 orig.tar. If at all dak keeps history of
the tar after so many releases. At that point, just uploading
1:22.3+debian will allow dak to accept the new tarball. Am I missing something here?
If this is indeed the case, it feels like many people are blindly
chanting epoch is evil without really understanding what is at stake
really.
On Fri, Aug 19, 2022 at 06:00:44PM +0100, Simon McVittie wrote:
Epochs cause problems, [...]
which are? (I agree they are ugly and should often be avoided, but I don't see any unsolved problems with them, which is why I'm asking.)
On Sat, Aug 20, 2022 at 03:29:59PM +0000, Stefano Rivera wrote:
The standard one is that people use them to revert an upload.Epochs cause problems, [...]which are? (I agree they are ugly and should often be avoided, but I don't >> > see any unsolved problems with them, which is why I'm asking.)
ok, I agree that's bad. (but not the case here.)
But, epochs aren't used in the upstream tarball filename, so you then
easily get a conflict between the old and the new one.
I'd replace 'easily' with 'theoretically in rare cases' but I can see how this is a valid point, sometimes.
Thanks for the feedback.
Quoting Yadd (2022-08-19 10:21:17)
some months ago, a bad upstream tag changed node-markdown-it version to 22.2.3 instead of 10.0.0. So I'd like to change node-markdown-it version into 1:13.0.1
Since upstream is already at 10, is it unlikely that they will reach 22
in the foreseeable future?
What I am getting at is that introducing an epoch is a pain *forever*
(all dependent packages must then *forever* remember to add "1:" prefix) wheread converting the accidental too-high major version into
pseudo-epoch "22.really." will last only until upstream catches up.
Note that the purpose of epochs is to cope with situations where the
upstream version numbering scheme changes and to allow us to leave
behind serious mistakes.
Someone using 22.something rather than 12.something in a version number,+1
to me, sounds like someone making a "serious mistake".
So this is *exactly* what epochs are meant for!
The something+reallysomethingelse convention is evil and should neverI find it very useful to temporarily downgrade a package. For
have been invented in the first place. It's extremely confusing to
users, and an epoch is *hidden* from them.
Someone using 22.something rather than 12.something in a version number,
to me, sounds like someone making a "serious mistake".
So this is *exactly* what epochs are meant for!
The something+reallysomethingelse convention is evil and should never
have been invented in the first place. It's extremely confusing to
users, and an epoch is *hidden* from them.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 27:53:06 |
| Calls: | 6,707 |
| Calls today: | 1 |
| Files: | 12,239 |
| Messages: | 5,352,697 |