As per comment #4 in bug 411751: > With multiple release trains in the same package, a ~arch version of the > "stable train" will never get tested by ~arch users. Therefore, I feel like > supporting multiple release trains for nginx in Gentoo is the wrong approach. Fair enough. > > I added myself to metadata.xml and will contribute to the dev't releases. It > is my opinion that we should just stabilize 1.1.19. Ok, in my opinion the best choise could be make a slot(stable and dev). So, Jeremy you can take care only of development release and if an user would use always ~arch version of stable slot, there is a way. Obvious the the slot should have a block for the other slot, www-client/google-chrome can be an example.
Oh dear, if upstream doesn't support slotting then downstream shouldn't. It is a maintenance nightmare.
Blocking slots are non-sense. If slotting, then permit parallel install. For nginx this would probably be easier than for other packages as it requires "only" to slot the following (in increasing order of complexity for slotting) * executable * init.d-scripts, {configuration,log}-dirs * perl-module But I'd like to second Hollow's idea: p.masking the unstable version is probably the easiest and most effective way.
i'm also in favor of p.masking the development branch. supporting slots would definitely be possible, but the nginx ebuild was always fairly simple (at least with regard to its number of modules) and i'd rather not introduce the complexity of supporting slots, just to keep people from accidentally upgrading to a different branch. Jeremy also asked about the differences between stable and development. This, of course, changes from time to time, and i also rarely follow the single diffs between the branches. But for an important package like nginx, i'd rather trust upstreams decision on stable and development than pushing the development version onto users just because we don't want to have untested ~arch ebuilds ... Jeremy, if you're ok with this, feel free to mask the 1.1 branch, otherwise i'll do it soonish, if nobody objects.
fine for me
Ok, I thought it over and I guess it makes sense. FTR, a diff of 1.0.15 and 1.1.19 is 7000 lines but mostly for debug, keepalive, pcre-jit, and spelling/syntax at 60 second glance Before 1.1 gets masked, what is the upgrade path / announcement for current ~arch users?
(In reply to comment #5) > Before 1.1 gets masked, what is the upgrade path / announcement for current > ~arch users? A post on planet and link it in a package.mask could be an idea?
This bug kind of solved itself. nginx-1.2.0 stable version has been released, incorporating many new features developed in the 1.1.x branch. So, moving forward, we can mask 1.3.0 (uncommitted at the moment) as it is the new development branch and we don't need to announce it.
indeed, very nice timing :-)
(my 2c) We didn't mask for previous uneven versions if I recall correctly (not since 0.7 anyway), and its not like its anything major. I would prefer unstable since I consider nginx 1.3.x being just as "unstable" as anything else we put in tree. We should just refrain from STABLEREQ:ing the 1.3.x branch.
(In reply to comment #9) > (my 2c) We didn't mask for previous uneven versions if I recall correctly > (not since 0.7 anyway), and its not like its anything major. I would prefer > unstable since I consider nginx 1.3.x being just as "unstable" as anything > else we put in tree. We should just refrain from STABLEREQ:ing the 1.3.x > branch. If you never want to stable the 1.3 line, then the 1.2 line will never get tested in ~arch (it is overshadowed) and that would be a poor scenerio for a stablereq.
Why not p.mask nginx until 1.2.0 gets a stablereq and after that move 1.3.x into ~arch? btw. app-emulation/wine has got the same problem. 1.4 is upstream's stable candidate and 1.5.x gets added to ~arch bi-weekly.
+ 06 Jun 2012; Patrick Lauer <patrick@gentoo.org> +nginx-1.3.1.ebuild: + Bump for #411937, temporarily masked I see no reason to leave it masked, but you figure out what's best ;)
(In reply to comment #12) > + 06 Jun 2012; Patrick Lauer <patrick@gentoo.org> +nginx-1.3.1.ebuild: > + Bump for #411937, temporarily masked > > I see no reason to leave it masked, but you figure out what's best ;) thx
1.2.x has had stable candidates for a while now. Can we please unmask 1.3.x? Upstream considers it being production ready: http://mailman.nginx.org/pipermail/nginx/2013-February/037552.html
The 1.4.x stable branch has been released and is in the tree but is masked as a result of this issue still.
(In reply to comment #15) > The 1.4.x stable branch has been released and is in the tree but is masked > as a result of this issue still. nginx-1.4 is not p.masked
