Re: [gentoo-dev] RFC Package name additions
On Sat, 17 Mar 2007 10:46:22 +0100 "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote: > One thing we could do would be to separate hierarchy from version > naming. This is where upstream version numbers fail to have a decent order (like your example where later versions have lower version numbers). It could be done for example by extending metadata to include definitions of unnatural ordering, but I don't think it's worth the effort. So far we deal with that on a case-by-case basis, and live with the pain when it occurs. > This would prevent cases like currently with rosegarden (~)1.2.4 > (~)1.4.0 4.1.0-r1 4.1.0-r2, where it really should be 4.1.0-r1 > 4.1.0-r2 (~)1.2.4 (~)1.4.0. For example, a simple solution is to just re-number the (presumably older) 4.* as 0.4.* and be done. That would also solve the potential future problem when the latest release reaches 4.* again. The sequence I would do is: 1) copy 4.1.0* to 0.4.1.0*, commit to the tree (here you could either rig the SRC_URI to keep the old tarball names, or copy the old tarballs again with the new revision number) 2) Alter any packages that depend on the 4.1 versions explicitly, to depend on the 0.4.1 versions (after you're sure the new 0.4.* versions are in the tree). 3) Remove the 4.1* versions - after a delay (a few days, a week, whatever, depending on how often your users are likely to update); in the changelog note that users should expect a downgrade and it is ok to do so. As a minimum, delay until you're sure (1) and (2) have reached the rsync mirrors. 4) Get 1.2*, 1.4* stablilised some time later in the normal way. Actually a quick scan of the tree shows there's nothing affected by (2) so that step can be skipped. I'd recommend still having a delay between the copy (1) and the removals (3) - at least long enough for the copies to propogate to the rsync mirrors before the removals happen (I'd probably do the copy one day, check that got through ok the next day and do the removals then). Noting the expected downgrade in the changelog when the higher-numbers are removed is important (this is what users will see if they do emerge -l). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
On Sat, 17 Mar 2007 14:01:45 +0100 Carsten Lohrke <[EMAIL PROTECTED]> wrote: > On Samstag, 17. März 2007, Jakub Moc wrote: > > Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by > > portage; dunno how does that fit the netbeans upstream scheme, though. > > The additional postfix is reserved exclusively for user local ebuilds, not > for > the ones provided by us. No, you're confusing it with a different idea that deals with extending the revision part (that isn't implemented yet). Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
On Sat, 2007-03-17 at 14:13 +0100, Carsten Lohrke wrote: > On Samstag, 17. März 2007, William L. Thomson Jr. wrote: > > IMHO I think it should be up to the package maintainer how close they > > want to follow upstream. With regard to development, progress, testing, > > qa, feedback. I think it's a very good thing, since it allows things to > > be caught before actual releases, during development. > > Doing this locally or in some development overlay is fine, but polluting the > tree with every single development build is a bad idea, imho. Well at best I might have 2 "development" versions in tree. But most times it's just one, and I will remove older versions during any bump. So hardly any polluting going on. Definitely no worse than what occurred when the package was going unmaintained :) Also in server envs, it seems most prefer not to use overlays. From my own experiences, I can't blame them much. Even for testing servers. They will usually divert and wait to test till it hits tree :( -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC Package name additions
On Sat, 2007-03-17 at 02:20 -0700, Ilya A. Volynets-Evenbakh wrote: > > There is a bit of contradiction in what you said there. > Either the package is well tested, and should go into the tree, first > with ~arch keywords, and then eventually with arch keywords, or > it is experimental, and as such has to be outside of our main tree. Well take Tomcat 6.0.x for example. I followed it's development and did many bumps over 3-4 months or so, from 6.0.2 to 6.0.10. Several in between went alpha, a few betas. They wanted to do several releases, but kept finding bugs or etc. That delayed a the release and caused them to do another bump on package version. Which after all that will likely be some time before they release > 6.0.10 :) Now sure if any Gentoo users contributed in that process. But at the same time, I would like to give those using this stuff as much notice as possible. So they can test in their own envs. Keep in mind most of this is server stuff. Most will want to test for some time before it gets deployed to a production env. From watching user comments on the developers list. Many are still running Tomcat 5.0.28 since there were issues in 5.5.x that were not resolved for years till 5.5.23 was released a few weeks ago. WRT Gentoo, part of the idea behind following upstream that closely. Allows us to hopefully identify any issues ahead of time. So when upstream does an official release. We can bump package, wait 30 days and stabilize. Without that being dragged out due to bug discoveries, and waiting for upstream to react after the fact. Tomcat did go unmaintained for about a year or so. Also trying to make up for that. Letting people know it will be active maintained. Which hopefully will encourage them to use Gentoo for their Java Server platform or etc. > Thus you can either want to test stuff by giving it more exposure, > which implies the stuff is experimental, or you have stable stuff, > but then you shouldn't be talking about the development cycle of the > said software. Any version of say Tomcat or mod_jk, I have put into tree before official release has been stable for me. Idea is to find out if it's stable for others as well. So while it's official status cause it to fall into experimental category. Most have no issues, and bugs do not tend to be very obvious or commonly run into. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC Package name additions
On Samstag, 17. März 2007, Petteri Räty wrote: > It's already used by alsa-driver. Then either me or the one doing so missed something on the discussion, why it was requested in the first place. Something to clarify in our ebuild policy. Carsten pgpUkMku2iZHo.pgp Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
On Sat, 17 Mar 2007 15:06:07 +0200 Petteri Räty <[EMAIL PROTECTED]> wrote: > Carsten Lohrke kirjoitti: > > On Samstag, 17. März 2007, Jakub Moc wrote: > >> Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and > >> honored by portage; dunno how does that fit the netbeans upstream > >> scheme, though. > > > > The additional postfix is reserved exclusively for user local > > ebuilds, not for the ones provided by us. > > > > > > Carsten > > It's already used by alsa-driver. And there's bug 166522 open about it. Some people consider Portage's acceptance of alsa-driver-like versions to be a bug. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
Carsten Lohrke napsal(a): > The additional postfix is reserved exclusively for user local ebuilds, not > for > the ones provided by us. Such as media-sound/alsa-driver-1.0.14_rc2_p3234 ? :) Anyway, if you have better ideas, move them to Bug 166522; multiple suffixes are definitely needed, just should be restricted to sane combos. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC Package name additions
> Well that's the problem. When I use say _pre instead of _dev it gives > off the wrong impression to users judging package by it's name. Since > it's not a pre-release. A user may go upstream looking for some sort of > pre-release. Which they won't find. We have stable, testing and masked ebuilds. Nothing else the user should care about. If he does, he can more closely looking what's up himself. Carsten pgpxB7QSMPAm9.pgp Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
On Samstag, 17. März 2007, William L. Thomson Jr. wrote: > IMHO I think it should be up to the package maintainer how close they > want to follow upstream. With regard to development, progress, testing, > qa, feedback. I think it's a very good thing, since it allows things to > be caught before actual releases, during development. Doing this locally or in some development overlay is fine, but polluting the tree with every single development build is a bad idea, imho. Carsten pgp1uJsUyuQ6N.pgp Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
This is a valid argument for a single postfix with a lower order than alpha, but not a reason to add everything what's out there. I don't see the need to match upstream's versioning bit by bit. Honestly said I've never understood why our order is alpha, beta, pre and not pre, alpha, beta, which would fix the issue and match more closely what happens in the tree. Changing this might break the one or the other dependency, though. Last but not least to add that I consider adding snapshots of regular releasing upstream projects as a waste of ressources. Carsten pgp1NJc2BVkzW.pgp Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
Carsten Lohrke kirjoitti: > On Samstag, 17. März 2007, Jakub Moc wrote: >> Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by >> portage; dunno how does that fit the netbeans upstream scheme, though. > > The additional postfix is reserved exclusively for user local ebuilds, not > for > the ones provided by us. > > > Carsten It's already used by alsa-driver. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC Package name additions
On Samstag, 17. März 2007, Jakub Moc wrote: > Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by > portage; dunno how does that fit the netbeans upstream scheme, though. The additional postfix is reserved exclusively for user local ebuilds, not for the ones provided by us. Carsten pgpGn5BppX9RK.pgp Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
On Sat, 17 Mar 2007 10:46:22 +0100 "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote: > One thing we could do would be to separate hierarchy from version > naming. That was one of Zynot's goals. You might want to investigate how they ended up solving it. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jakub Moc napsal(a): > Miroslav Šulc (fordfrog) napsal(a): >> According to >> http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules >> it seems to me the versioning is focused on package stability life >> cycle. In netbeans case it is _prealpha and definitely not stable >> patched release. So _alpha is the closest one to current netbeans 6.0 >> life cycle phase, though not accurate. > > Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by > portage; dunno how does that fit the netbeans upstream scheme, though. Where does this come from? There is nothing about it in devmanual. And is '_alpha > _alpha_pre' true of false? Anyway I'd rather preffer _prealpha than _alpha_pre :-) - -- Miroslav Šulc (fordfrog) Gentoo/Java Team -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+9m2RSzWCmqu+0YRAt+3AJ9RcqsIgCzlJCygKyRrqEGZY6lmogCffLWl ZdCUglDhgQAiBaop7G1dXM4= =14Rp -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: > On Fri, 16 Mar 2007 18:25:17 -0400 > "William L. Thomson Jr." <[EMAIL PROTECTED]> wrote: > >> Hierarchy would be the following >> >> snapshot -> dev -> build -> alpha -> beta > > And that's where the problems start. As you said yourself _snapshot is > something universal so it doesn't really fit anywhere in the chain. > Similar for _build, it usually runs parallel to normal versioning (a > release also has a build number). Don't know about _dev, never seen a > package where that would be useful myself. > And as has been said, there are compability issues. At best older > portage versions would ignore ebuilds using these new suffixes > resulting in confused users, worst case stuff starts breaking. > If you want to pursue this you should get some numbers of how many > packages could actually make use of these new features, it simply isn't > worth thinking about it for just a handful of packages. > > Marius One thing we could do would be to separate hierarchy from version naming. That way we can allow arbitrary version names and also smoothly traverse version scheme changes such that break hierarchy. This would prevent cases like currently with rosegarden (~)1.2.4 (~)1.4.0 4.1.0-r1 4.1.0-r2, where it really should be 4.1.0-r1 4.1.0-r2 (~)1.2.4 (~)1.4.0. We could also add an internal version which would be compared first and only if it is equal for packages would the version in the ebuild name be used for ordering. Just throwing some ideas out there, Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+7jup/VmCx0OL2wRAhszAJwNo29AEj6rOSlimu+sbi8OwUPeKgCePo2g 2g1sI/Tk+ZYnRQ0j8b7d+44= =SdRi -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
Miroslav Šulc (fordfrog) napsal(a): > According to > http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules > it seems to me the versioning is focused on package stability life > cycle. In netbeans case it is _prealpha and definitely not stable > patched release. So _alpha is the closest one to current netbeans 6.0 > life cycle phase, though not accurate. Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by portage; dunno how does that fit the netbeans upstream scheme, though. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC Package name additions
William L. Thomson Jr. wrote: > IMHO I think it should be up to the package maintainer how close they > want to follow upstream. With regard to development, progress, testing, > qa, feedback. I think it's a very good thing, since it allows things to > be caught before actual releases, during development. > > I know when I am developing stuff, it's way easier to address during the > process rather than after the fact. > > But if there are any policies or etc. I surely do not want to be > breaking them. Also this is not broken or really experimental stuff. If > it was I would either p.mask, or put in an overlay. > > Although I feel things tend to get the greatest exposure and chance of > user testing and feedback, if it's in tree There is a bit of contradiction in what you said there. Either the package is well tested, and should go into the tree, first with ~arch keywords, and then eventually with arch keywords, or it is experimental, and as such has to be outside of our main tree. Thus you can either want to test stuff by giving it more exposure, which implies the stuff is experimental, or you have stable stuff, but then you shouldn't be talking about the development cycle of the said software. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules it seems to me the versioning is focused on package stability life cycle. In netbeans case it is _prealpha and definitely not stable patched release. So _alpha is the closest one to current netbeans 6.0 life cycle phase, though not accurate. - -- Miroslav Šulc (fordfrog) Gentoo/Java Team Mike Frysinger napsal(a): > On Friday 16 March 2007, Miroslav Šulc (fordfrog) wrote: >> Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does >> milestone releases. These are pretty stable and usable since milestone 7 >> of netbeans 6.0 with many new features that make sense to use the >> milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc. >> though I was assured by mkt guy from Sun it is not yet alpha quality. It >> would be fair to the upstream and to users to not use _alpha because it >> is not alpha but there's no appropriate choice available. > > i would use _p# over _alpha# > -mike -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+6oPRSzWCmqu+0YRAhPAAJ99Et9Uwk/JrpRPkukABgrc3CdLfQCghrm+ noRpxMDQvlxrlLhFUdqb088= =gC2k -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
On Sat, 2007-03-17 at 01:08 -0700, Ilya A. Volynets-Evenbakh wrote: > Rather then analyze the proposed solution, I'd like to > question the problem itself. Do we really want to provide > all the different intermediate development "sort of releases" > in our tree? That came up in the link I provided in another post. http://marc.info/?l=tomcat-dev&m=117251925901310&w=2 IMHO I think it should be up to the package maintainer how close they want to follow upstream. With regard to development, progress, testing, qa, feedback. I think it's a very good thing, since it allows things to be caught before actual releases, during development. I know when I am developing stuff, it's way easier to address during the process rather than after the fact. But if there are any policies or etc. I surely do not want to be breaking them. Also this is not broken or really experimental stuff. If it was I would either p.mask, or put in an overlay. Although I feel things tend to get the greatest exposure and chance of user testing and feedback, if it's in tree. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC Package name additions
Rather then analyze the proposed solution, I'd like to question the problem itself. Do we really want to provide all the different intermediate development "sort of releases" in our tree? William L. Thomson Jr. wrote: > After reviewing > > http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules > > > I still seem to be having to finagle version names for some packages. At > the moment it would be nice if we also had the following suffixes > available > > _dev > Apache upstream, specifically Tomcat/mod_jk tends to do developer > snapshots that they then host out of developer space. People do fetch > bins and source from there for testing. It's kinda pre-release, so I > have been using _pre where I would use _dev, but _pre does not make much > sense. > > _build > Other packages seem to do constant builds (weekly) of the same version. > For example Glassfish (Sun's FOSS J2EE stuff). It's sources are v2-b39. > So would be nice to be able to do like glassfish-servlet-api-2_build39 > > _snapshot > This one is kinda universal in it's name/implication. Would be for any > sort of upstream snapshot release, that might not be versioned as such. > Short of the name snapshot being some where. > > The above would then follow the rest of the normal schema, where in they > could still be suffixed by a number, or not. > > Hierarchy would be the following > > snapshot -> dev -> build -> alpha -> beta > > Or at least that's my thoughts on it. Time for others thoughts, much > less those that will make it so. Not expecting it to get done or be > available any time soon. Would be suffice if they were just accepted and > planned for inclusion at some point. > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
On Fri, Mar 16, 2007 at 09:24:33PM -0400, Mike Frysinger wrote: > On Friday 16 March 2007, Miroslav Šulc (fordfrog) wrote: > > Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does > > milestone releases. These are pretty stable and usable since milestone 7 > > of netbeans 6.0 with many new features that make sense to use the > > milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc. > > though I was assured by mkt guy from Sun it is not yet alpha quality. It > > would be fair to the upstream and to users to not use _alpha because it > > is not alpha but there's no appropriate choice available. > > i would use _p# over _alpha# 6.0_p7 is considered a higher version than 6.0, right? That will probably cause problems in the future. _pre# may be a good choice, though. pgpAEes51I0pb.pgp Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
William L. Thomson Jr. wrote: > On Sat, 2007-03-17 at 03:11 +0100, Marius Mauch wrote: >> On Fri, 16 Mar 2007 18:25:17 -0400 >> "William L. Thomson Jr." <[EMAIL PROTECTED]> wrote: >> >>> Hierarchy would be the following >>> >>> snapshot -> dev -> build -> alpha -> beta >> And that's where the problems start. As you said yourself _snapshot is >> something universal so it doesn't really fit anywhere in the chain. > > Yes, order wise snapshots might be quite confusing. Not sure if a well > defined definition would clear that up. > >> Similar for _build, it usually runs parallel to normal versioning (a >> release also has a build number). > > That's more something specific to say glassfish where builds are weekly > https://glassfish.dev.java.net/public/downloadsindex.html#Promoted_binary_builds > > With major ones being milestones, similar to Netbeans. > https://glassfish.dev.java.net/public/downloadsindex.html#Milestone_binary_builds > > Glassfish alone is likely to comprise of a guestimated ~20 or so > packages. It's Sun's formerly closed source J2EE stack for the most > part. Very possible could be more, formerly know as WSDP > http://java.sun.com/webservices/jwsdp/index.jsp > >> At best older >> portage versions would ignore ebuilds using these new suffixes >> resulting in confused users, worst case stuff starts breaking. >> If you want to pursue this you should get some numbers of how many >> packages could actually make use of these new features, it simply isn't >> worth thinking about it for just a handful of packages. Bleh; you have to break it at one point anyhow; you added the cvs suffix, no? :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
On Sat, 2007-03-17 at 03:11 +0100, Marius Mauch wrote: > On Fri, 16 Mar 2007 18:25:17 -0400 > "William L. Thomson Jr." <[EMAIL PROTECTED]> wrote: > > > Hierarchy would be the following > > > > snapshot -> dev -> build -> alpha -> beta > > And that's where the problems start. As you said yourself _snapshot is > something universal so it doesn't really fit anywhere in the chain. Yes, order wise snapshots might be quite confusing. Not sure if a well defined definition would clear that up. > Similar for _build, it usually runs parallel to normal versioning (a > release also has a build number). That's more something specific to say glassfish where builds are weekly https://glassfish.dev.java.net/public/downloadsindex.html#Promoted_binary_builds With major ones being milestones, similar to Netbeans. https://glassfish.dev.java.net/public/downloadsindex.html#Milestone_binary_builds Glassfish alone is likely to comprise of a guestimated ~20 or so packages. It's Sun's formerly closed source J2EE stack for the most part. Very possible could be more, formerly know as WSDP http://java.sun.com/webservices/jwsdp/index.jsp > At best older > portage versions would ignore ebuilds using these new suffixes > resulting in confused users, worst case stuff starts breaking. > If you want to pursue this you should get some numbers of how many > packages could actually make use of these new features, it simply isn't > worth thinking about it for just a handful of packages. After others comments, this is definitely something for the future. If and a time comes that it's feasible to introduce such changes safely. I do agree before acceptable or implementation the amount of packages that can benefit from it would surely help justify it or not. Now I doubt it's feasible for me alone to figure out if it can benefit all 4k+ packages :) So hopefully others can chime in briefly on if they can benefit or not. Maybe email me directly to I can start a tally. Only if you have packages that can benefit, no need otherwise. With that said, what percentage or ruff # of packages do you all think would need to benefit to justify it? That way if it's hard to find say 50 and min is like 500+, then no reason to look into it any further. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC Package name additions
On Fri, 2007-03-16 at 21:23 -0400, Mike Frysinger wrote: > On Friday 16 March 2007, William L. Thomson Jr. wrote: > > Well that's the problem. When I use say _pre instead of _dev it gives > > off the wrong impression to users judging package by it's name. Since > > it's not a pre-release. A user may go upstream looking for some sort of > > pre-release. Which they won't find. > > isnt it though ? how is a "development" release different from a "pre" > release ? I take it as a pre-release is more of an official release. Where in it would be easily found on a projects download page or else where. What I would consider a _dev release is something coming out of a developers space on the project. Not really announced say beyond the developers mailing list. In that same regard alpha's and beta's usually can be found on project download pages. Same I would assume for any pre-releases. Given conceptually a development release is "pre" release. But not really advertised as such by upstream. Either way it would not really fit into our hierarchy. Most times the dev release will precede an alpha or beta, sometimes does skip and is before an official release. This might help a bit http://marc.info/?l=tomcat-dev&m=117251925901310&w=2 In that example a _dev is more of a snapshot, which could also be considered as pre-release :) Good old interpretation of words. P.S. OTT With regard to above link and following development that closely. Between revisions of mod_jk, not only was there a security vulnerability. But in compatible changes effect certain file extensions .jsf, that a user reported. Which they only mentioned during stabilization of a given version (literally in stabilization bug). So in a sense a version with a problem got stabilized. But was an upstream bug, effecting a small subset. So did not really merit keeping the package from going stable for others. But bug was not filed with upstream either till 30+ days after release due to our stabilization policies and etc. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC Package name additions
On Fri, 16 Mar 2007 18:25:17 -0400 "William L. Thomson Jr." <[EMAIL PROTECTED]> wrote: > Hierarchy would be the following > > snapshot -> dev -> build -> alpha -> beta And that's where the problems start. As you said yourself _snapshot is something universal so it doesn't really fit anywhere in the chain. Similar for _build, it usually runs parallel to normal versioning (a release also has a build number). Don't know about _dev, never seen a package where that would be useful myself. And as has been said, there are compability issues. At best older portage versions would ignore ebuilds using these new suffixes resulting in confused users, worst case stuff starts breaking. If you want to pursue this you should get some numbers of how many packages could actually make use of these new features, it simply isn't worth thinking about it for just a handful of packages. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
On Friday 16 March 2007, Miroslav Šulc (fordfrog) wrote: > Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does > milestone releases. These are pretty stable and usable since milestone 7 > of netbeans 6.0 with many new features that make sense to use the > milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc. > though I was assured by mkt guy from Sun it is not yet alpha quality. It > would be fair to the upstream and to users to not use _alpha because it > is not alpha but there's no appropriate choice available. i would use _p# over _alpha# -mike pgpCf7QYn7X2T.pgp Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
On Friday 16 March 2007, William L. Thomson Jr. wrote: > Well that's the problem. When I use say _pre instead of _dev it gives > off the wrong impression to users judging package by it's name. Since > it's not a pre-release. A user may go upstream looking for some sort of > pre-release. Which they won't find. isnt it though ? how is a "development" release different from a "pre" release ? -mike pgpeE8TY4c1A7.pgp Description: PGP signature
Re: [gentoo-dev] RFC Package name additions
William L. Thomson Jr. said the following: > > Well that's the problem. When I use say _pre instead of _dev it gives > off the wrong impression to users judging package by it's name. Since > it's not a pre-release. A user may go upstream looking for some sort of > pre-release. Which they won't find. > > The whole point is to make it clearer to the user the relation of the > sources to upstream. Instead of making them fit into our naming schema, > which do not apply to all. > The whole idea is better clarification to the end user via package name. > Instead of package being tagged as _pre or etc, and sources being tagged > with -dev and/or coming from a developers space. Not main project > release page or etc. > Hi guys, As one of the aforementioned users, I think the goal of helping us get a better idea of the "reliability" a given package is excellent. I was looking at the GLEP list the other day, and one of them that I liked in particular was GLEP 46. (Allow upstream tags in metadata). I think it could have some bearing on this goal. Although the GLEP doesn't list "upstream-version" as one of its proposed metadata tags, I think it could fit in nicely. I have no clue what the status of that GLEP is, but maybe the authors would? Personally, I think it sounds like a good flexible way of adding information to an ebuild without needing to redo the naming scheme, or the upgrade path. Here, you could use one of the existing ways of naming the package, but in the metadata give the information a user would want to evaluate the package's reliability (plus more!) :) -nkm -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
On Fri, 16 Mar 2007 20:00:51 -0400 "William L. Thomson Jr." <[EMAIL PROTECTED]> wrote: > Understandable for sure. Thus not really putting any sort of time > frame on implementation. Maybe EAPI=1 or beyond. Up to others that > would implement it. Just was tossing it out there, providing some > feedback. EAPI doesn't help, at least not in its current form. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
On Fri, 2007-03-16 at 23:46 +, Stephen Bennett wrote: > On Sat, 17 Mar 2007 00:11:43 +0100 > Carsten Lohrke <[EMAIL PROTECTED]> wrote: > > > There's absolutely no reason to absorb every single version naming > > scheme on earth. Gentoo's does work nicely and more than we have > > would only be irritating to the user. Simply use _pre or > > whatever fits, but extending our naming scheme is unneeded and > > pointless. > > And of course there is the issue of how older Portage releases will > react to ebuild names that they don't understand. Understandable for sure. Thus not really putting any sort of time frame on implementation. Maybe EAPI=1 or beyond. Up to others that would implement it. Just was tossing it out there, providing some feedback. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC Package name additions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does milestone releases. These are pretty stable and usable since milestone 7 of netbeans 6.0 with many new features that make sense to use the milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc. though I was assured by mkt guy from Sun it is not yet alpha quality. It would be fair to the upstream and to users to not use _alpha because it is not alpha but there's no appropriate choice available. - -- Miroslav Šulc (fordfrog) Gentoo/Java Team William L. Thomson Jr. napsal(a): > After reviewing > > http://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules > > > I still seem to be having to finagle version names for some packages. At > the moment it would be nice if we also had the following suffixes > available > > _dev > Apache upstream, specifically Tomcat/mod_jk tends to do developer > snapshots that they then host out of developer space. People do fetch > bins and source from there for testing. It's kinda pre-release, so I > have been using _pre where I would use _dev, but _pre does not make much > sense. > > _build > Other packages seem to do constant builds (weekly) of the same version. > For example Glassfish (Sun's FOSS J2EE stuff). It's sources are v2-b39. > So would be nice to be able to do like glassfish-servlet-api-2_build39 > > _snapshot > This one is kinda universal in it's name/implication. Would be for any > sort of upstream snapshot release, that might not be versioned as such. > Short of the name snapshot being some where. > > The above would then follow the rest of the normal schema, where in they > could still be suffixed by a number, or not. > > Hierarchy would be the following > > snapshot -> dev -> build -> alpha -> beta > > Or at least that's my thoughts on it. Time for others thoughts, much > less those that will make it so. Not expecting it to get done or be > available any time soon. Would be suffice if they were just accepted and > planned for inclusion at some point. > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+yssRSzWCmqu+0YRAoQAAJ9XHz0wZL3pdkSzSyxnVRnLsrw4FwCfVMDO vuDOHvpko+t1nhu1cvx0RfY= =ZYFd -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
On Sat, 17 Mar 2007 00:11:43 +0100 Carsten Lohrke <[EMAIL PROTECTED]> wrote: > There's absolutely no reason to absorb every single version naming > scheme on earth. Gentoo's does work nicely and more than we have > would only be irritating to the user. Simply use _pre or > whatever fits, but extending our naming scheme is unneeded and > pointless. And of course there is the issue of how older Portage releases will react to ebuild names that they don't understand. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC Package name additions
On Sat, 2007-03-17 at 00:11 +0100, Carsten Lohrke wrote: > There's absolutely no reason to absorb every single version naming scheme on > earth. Gentoo's does work nicely and more than we have would only be > irritating to the user. Simply use _pre or whatever fits, but > extending our naming scheme is unneeded and pointless. Well that's the problem. When I use say _pre instead of _dev it gives off the wrong impression to users judging package by it's name. Since it's not a pre-release. A user may go upstream looking for some sort of pre-release. Which they won't find. The whole point is to make it clearer to the user the relation of the sources to upstream. Instead of making them fit into our naming schema, which do not apply to all. Now granted at least on the Java front we have discussed coming up with documents. We have a start of one, How to be a good upstream http://overlays.gentoo.org/proj/java/wiki/How_to_be_a_good_upstream Which we do need to make a section regarding package naming, tagging sources and etc. With examples and so on. Also keep in mind the _dev one I believe stems from Apache's own release policies. Which they have a considerable amount of packages, so it's not something that would only fit a small subset. IE Tomcat, mod_jk, etc. The whole idea is better clarification to the end user via package name. Instead of package being tagged as _pre or etc, and sources being tagged with -dev and/or coming from a developers space. Not main project release page or etc. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC Package name additions
There's absolutely no reason to absorb every single version naming scheme on earth. Gentoo's does work nicely and more than we have would only be irritating to the user. Simply use _pre or whatever fits, but extending our naming scheme is unneeded and pointless. Carsten pgpcLcObgCmuK.pgp Description: PGP signature
