I realize many people do not like to move to a new version of corosync until it has been field-tested for awhile, yet we are nearing a point when 1.4.0 with SNMP support is usable and ready for release. If we released this today, everyone on 1.3.0 would be unable to get bug fixes for 1.3.0 from a project generated tarball given our current policies.
As a result, in the future, we will maintain the latest 2 y branches. I have created a new 1.3 branch called flatiron-1.3 to contain the y branch for flatiron 1.3. Example of how this works: Any bug fix that hits master will go into flatiron branch Any bug fix in flatiron branch will go into flatiron-1.3 When 1.4 is ready for release, a flatiron-1.4 branch will be created from the flatiron branch. At this point, any bug fix will go into both the flatiron-1.3 and flatiron-1.4 branches New features which are selected for flatiron will go into the flatiron branch and form the basis of a flatiron-1.5 branch When 1.5 flatiron branch is released, the flatiron-1.3 branch will become unmaintained. This allows a nice stable field tested y-1 release and a nice stable tested y release which may have a bit more features. Note the requirements for stable branches are still very high and include complete validation with our automated test runs. Note I use the above as an example, I don't expect us to release a flatiron 1.5. Regards -steve _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
