Re: New version bali-phy 4.0-beta2
Am Mon, Apr 03, 2023 at 09:34:13AM -0400 schrieb Benjamin Redelings: > > I tried a few things, but haven't figured this out yet. I see there is > versionmangle, dversionmangle, and uversionmangle. I see that we want the > debian version to be 4.0~beta2, not 4.0-beta2 (i.e. with a tilde). I will > try again later. Just check my latest commit (or upload to experimental). > I am the upstream :-) I understand the reasoning though. I don't think you > should package all betas, but in this case (i.e. for version 4.0-beta2), as > the upstream I feel like its the right thing to do. > > I could relabel this as version 4.0, but I would prefer not to, since there > are some features that I want to add before I label this as 4.0. > > Perhaps this does not matter, since it would be uploaded to experimental > anyway. ... which was done right now. Kind regards Andreas. -- http://fam-tille.de
Re: New version bali-phy 4.0-beta2
Hi, Thanks for the advice! On 3/29/23 3:04 PM, Andreas Tille wrote: Hi Benjamin, Am Tue, Mar 28, 2023 at 07:04:52AM +0200 schrieb Pierre Gruet: Probably you wouold like to do something as in https://sources.debian.org/src/gedit-plugins/44.1-2/debian/watch/?hl=2#L2 for the gedit-plugins package? This was found by typing "path:debian/watch beta" in the search field of sources.debian.org. There are other packages which you could check there. ACK. I tried a few things, but haven't figured this out yet. I see there is versionmangle, dversionmangle, and uversionmangle. I see that we want the debian version to be 4.0~beta2, not 4.0-beta2 (i.e. with a tilde). I will try again later. Secondly, I suppose that any new version would need to go into experimental, since we are in a hard freeze? I would like to start working on packaging for version 4 now, since some things have changed and I'd like to figure out how to deal with them now. Yes, uploading to experimental is the right thing to do right now :) I'm wondering whether any beta versions should go to experimental in general. The fact that upstream marks it as beta is usually a sign that the code is not for end users production systems. I wrote a couple of watch files that do not even report any alpha/beta versions as new version. I am the upstream :-) I understand the reasoning though. I don't think you should package all betas, but in this case (i.e. for version 4.0-beta2), as the upstream I feel like its the right thing to do. I could relabel this as version 4.0, but I would prefer not to, since there are some features that I want to add before I label this as 4.0. Perhaps this does not matter, since it would be uploaded to experimental anyway. -BenRI Kind regards Andreas.
Re: New version bali-phy 4.0-beta2
Hi Andreas, Le 2023-03-29 21:04, Andreas Tille a écrit : Hi Benjamin, Am Tue, Mar 28, 2023 at 07:04:52AM +0200 schrieb Pierre Gruet: Probably you wouold like to do something as in https://sources.debian.org/src/gedit-plugins/44.1-2/debian/watch/?hl=2#L2 for the gedit-plugins package? This was found by typing "path:debian/watch beta" in the search field of sources.debian.org. There are other packages which you could check there. ACK. > Secondly, I suppose that any new version would need to go into > experimental, since we are in a hard freeze? I would like to start > working on packaging for version 4 now, since some things have changed > and I'd like to figure out how to deal with them now. Yes, uploading to experimental is the right thing to do right now :) I'm wondering whether any beta versions should go to experimental in general. The fact that upstream marks it as beta is usually a sign that the code is not for end users production systems. I wrote a couple of watch files that do not even report any alpha/beta versions as new version. This makes sense, right. It happened that I used experimental to examine some issues (e.g. on some architectures) with beta versions, but yeah, there is always the risk that such unreliable version lands into unstable after some not-careful-enough upload. Kind regards Andreas. Best, -- Pierre
Re: New version bali-phy 4.0-beta2
Hi Benjamin, Am Tue, Mar 28, 2023 at 07:04:52AM +0200 schrieb Pierre Gruet: > Probably you wouold like to do something as in > > https://sources.debian.org/src/gedit-plugins/44.1-2/debian/watch/?hl=2#L2 > for the gedit-plugins package? This was found by typing "path:debian/watch > beta" in the search field of sources.debian.org. There are other packages > which you could check there. ACK. > > Secondly, I suppose that any new version would need to go into > > experimental, since we are in a hard freeze? I would like to start > > working on packaging for version 4 now, since some things have changed > > and I'd like to figure out how to deal with them now. > > Yes, uploading to experimental is the right thing to do right now :) I'm wondering whether any beta versions should go to experimental in general. The fact that upstream marks it as beta is usually a sign that the code is not for end users production systems. I wrote a couple of watch files that do not even report any alpha/beta versions as new version. Kind regards Andreas. -- http://fam-tille.de
Re: New version bali-phy 4.0-beta2
Hi Benjamin, Le 28/03/2023 à 03:52, Benjamin Redelings a écrit : Hi, I'd like to upload a new version 4.0-beta2 of bali-phy. It decreases memory usage over the existing 3.6.1 by > 20fold in some cases. The first question I have is about using uscan with the "-beta2" suffix. I hacked the debian/watch file to make uscan recognize the tag name, but now its creating a dfsg source file called `bali-phy_4.0+dfsg.orig.tar.xz`. I suspect this should really be called `bali-phy_4.0-beta2+dfsg.orig.tar.xz`. Any guidance on how to handle -beta versions? I guess normally we may not want these, but in this case I think we do. Probably you wouold like to do something as in https://sources.debian.org/src/gedit-plugins/44.1-2/debian/watch/?hl=2#L2 for the gedit-plugins package? This was found by typing "path:debian/watch beta" in the search field of sources.debian.org. There are other packages which you could check there. Secondly, I suppose that any new version would need to go into experimental, since we are in a hard freeze? I would like to start working on packaging for version 4 now, since some things have changed and I'd like to figure out how to deal with them now. Yes, uploading to experimental is the right thing to do right now :) -BenRI Have a good day, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
New version bali-phy 4.0-beta2
Hi, I'd like to upload a new version 4.0-beta2 of bali-phy. It decreases memory usage over the existing 3.6.1 by > 20fold in some cases. The first question I have is about using uscan with the "-beta2" suffix. I hacked the debian/watch file to make uscan recognize the tag name, but now its creating a dfsg source file called `bali-phy_4.0+dfsg.orig.tar.xz`. I suspect this should really be called `bali-phy_4.0-beta2+dfsg.orig.tar.xz`. Any guidance on how to handle -beta versions? I guess normally we may not want these, but in this case I think we do. Secondly, I suppose that any new version would need to go into experimental, since we are in a hard freeze? I would like to start working on packaging for version 4 now, since some things have changed and I'd like to figure out how to deal with them now. -BenRI
