After some cosmetic ebuild changes and no bugs I suggest to mark app-editors/scite-3.6.4 stable. This obsoletes bug #577882. Have a nice day, ervin
commit aa9fbd757f0eb2345f1702affb3ada5352cfad2f does not constitute a minor change. You changed slotting of several dependencies as well as dropped one. For the drop of sed, while it is a system package, anyone who has the old version of your ebuild will have sed in their depgraph as a result. Depgraph changes warrant a revbump. Additionally, with GTK, the package scite does in fact support GTK3 (and you probably should consider adding that support, but that's a side note). Your previous ebuild allowed GTK3 to satisfy the depgraph, while the ebuild as is depends on GTK2, meaning it's possible to have depgraph breakage/package breakage if you remove GTK2 from your system. It should have been a revision bump (hint hint). Due to these non-minor changes and impending revbump, stabilization should wait a month from that commit, as per norm.
I have an alternative suggestion. Considering the obligatory wait of 30 days and the scite-3.6.5.ebuild carries all the updated improvements, that version will equally qualify. While the revbumps may have been missed, the version 3.6.5 once made stable will make all prior versions old and prone to purging. In fact, scite-3.6.2.ebuild, scite-3.6.4.ebuild qualify now to be purged. If it were not for suggesting scite-3.6.4 to be made stable to supersede 3.5.5, I would have suggested purging both then, so as to pursue the practice of having old versions cleared, preventing bloat of the tree. as per norm. As for incorporating GTK3, your call. Either way yes the stabilising of this is to await June 5 in a state free of open bugs.
(In reply to Ian Delaney from comment #2) > I have an alternative suggestion. > Considering the obligatory wait of 30 days and the scite-3.6.5.ebuild > carries all the updated improvements, that version will equally qualify. > While the revbumps may have been missed, the version 3.6.5 once made stable > will make all prior versions old and prone to purging. > In fact, scite-3.6.2.ebuild, scite-3.6.4.ebuild qualify now to be purged. If > it were not for suggesting scite-3.6.4 to be made stable to supersede 3.5.5, > I would have suggested purging both then, so as to pursue the practice of > having old versions cleared, preventing bloat of the tree. as per norm. That makes sense to me. > As for incorporating GTK3, your call. scite-3.6.6 is announced for mai 23rd. If I find time I'll try to figure out how to improve the ebuild to use gtk3 ervin
bug #583204 suggested scite-3.6.5-r1 with gtk3 support. maybe this should be the next stable version. All unstable versions < scite-3.6.5 could be purged - imho. (See Ian Delaneys last comment) ervin
