https://bugzilla.redhat.com/show_bug.cgi?id=1055378 --- Comment #11 from Michael Friedrich <michael.friedrich@xxxxxxxxx> --- (In reply to Christopher Meng from comment #10) > (In reply to Michael Friedrich from comment #9) > > While the transition/upgrade from 1.x to 2.x may not be the easiest > > (although we're trying very hard), they can run side by side and won't harm > > each other. Having both packages installed won't hurt the system, they run > > happily on my laptop every day during development. > > EPEL packages shouldn't be bumped from 1.x series to 2.x series, once it > gets into EPEL, nothing should be changed with the major version. For epel7, > since it's not ready, we can bump to anuthing you want, so if we want to > ship this package: Still, if a package is named "icinga" and one "icinga2", that would signal a difference to the user, wouldn't it? > > 1. Create a package "icinga", with 2.x version, and then create a package > icinga1, with 1.x version. > > 2. Create "icinga" only with 2.x, seems objected by some people > > 3. My opinion: create "icinga" only, but different version in different > branch. > > Fedora ships 2.x, EPEL6 ships 1.x, EPEL7 ships 2.x. > > But it's still not a perfect idea IMO. :) > > 4. Your opinion here. Given the current stack of Icinga we have now Supported * Icinga Core, Classic UI, IDOUtils * Icinga Web (1.0) * Icinga Reporting (requires Jasperserver, cannot be packaged easily) Unreleased - both are rewrites from scratch * Icinga 2 (Core) * Icinga Web (2.0) The problem with versions on a single package reflecting 1.0 and 2.0 are most likely that users expect a smooth transition and upgrade path. Which cannot be guarantueed due to the nature of both being rewrites. There are different modules around as well. In Icinga 1.x there's the NEB API allowing binary modules to register callbacks. IDOUtils dumps them to the database, others such as livestatus act as addon packages to be installed only with Icinga 1.x The Icinga 2 interfaces are binary incompatible with that NEB API. Still it ships its own featureset as replacement (featues such as DB IDO, Livestatus, etc directly implemented). The problem I do see here - the package names are different in 1.x and 2.x Therefore, I would still vote to bring 1.x as the standard packages into Fedora/EPEL now, and then opt for the 2.x branch once it's become ready. And if 2.x must reside on an experimental repository tree due to problems with 2 different package versions - well, gotta live with that. It took long-term to finally have php53 in RHEL5 anyways. > > > Once Icinga (Web) 2.x are ready for their final releases (hopefully Q2 but > > never say never), packages and review requests should be pushed seperately > > imho. If you want to testdrive Icinga 2 RPMs - Snapshot SRPMs are available > > here http://packages.icinga.org/epel/6/snapshot/src/ > > Which version is better, and can receive updates in the next 10 years? Funny. The SUSE guys asked me the same question for SLES12. The 10 year support strategy hurts, really. I do understand it, but from an open source project's point of view it's hard to actually guarantuee that. In any attempt, the 1.x branch will be supported as long as needed. There may not be that many features in the future, but bug fixes, security issues, etc will be resolved in short response times as already known from the past 5 years. In terms of features and additions, the 2.x branch receives plenty of development resources currently and probably will in the future, depending on sponsors and contributions. Though it must be proven stable. Team Icinga doesn't have any numbers (Icinga doesn't phone home) of official Icinga installations out there, but the 1.x branch is installed everywhere and that won't change that soon in the next decade. The monitoring community is somewhat "lazy" in terms of upgrading to new versions, and won't change running systems. Therefore going the 1.x route for stability is imho the right way. Last but not least, we probably should move the discussion on the 2.x branch to a seperate issue / mailinglist not to spam the review here. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review