On 07/19/2012 07:43 PM, Roberto C. Sánchez wrote: > On Fri, Jul 20, 2012 at 08:57:45AM +1000, Paul Gear wrote: >> >> I agree with Jonathan. With my non-packager, mostly-non-developer hat >> on, i think that keeping the versions lock-stepped follows the principle >> of least surprise for Shorewall's users. It might save hours of effort >> for developers & packagers by not having them lock-stepped, but it will >> save hundreds of hours of confusion and dozens of questions on the >> mailing list if we keep it the way it is. >> > On the flip side, Debian has just entered the freeze period for the next > stable release. So, any new releases introduced into Debian must > reeceive a freeze exception in order to be allowed to propogate. Since > it is the practice of the release managers to not allow gratiutous > changes, I have to choose one of these options: > > 1) (assuming all packages are released each time) I upload only the > packages which actually changed (potentially confuses users since the > Debian packages get out of sync with respect to version numbers > i.e., they are not all in lock step) > > 2) (assuming all packages are released each time) I patch in the > specific changes and upload them as a new Debian revision, which > risks confusing users even more > > 3) (assuming only changed packages are released each time) I keep the > Debian packages in sync and there is no confusion since upstream and > Debian match up > > Personally, I like the last option, since that would be the "least > surprise" to me (and I would think to users). Of course, there are > people out there using just upstream packages or just Debian packages, > and they are not likely to be affected inconsistencies between available > versions of Debian packages and upstream packages. > > Incidentally. when Debian is not frozen, this is not a major issu since > I can make "gratiutous" uploads and no special action is required in > order to get the packages propagated to testing. > > Also, keep in mind that there are other software systems out there that > are modular in nature that do not keep all components in lock step. For > example, the Horde framework has lots of different components. > Sometimes releases are synchronized, but oftentimes they are not. >
I think that this boils down to an issue with the Debian freeze period. Were it not for the preference of the Debian release team to only accept uploads that actually correct problems, we would all agree that it is less confusing for users to have a matched set of components. Regarding your second approach above, I notice that Debian (and most other distros) add a "-n" to my version number. So my 4.5.5.3 is released as 4.5.5.3-1. So presumably, users would not be confused if they saw shorewall-core-4.5.5.3-1 and shorewall-4.5.5.3-2? If I were to release individual patches along with the consolidated patch for each product, would that help (I would only need to do that during the freeze period). You could then apply those patches that did not bump the version number and upload the patched product as -2, -3, etc. It would be more work for the two of us during the freeze period but would spare everyone else. An alternative would be for me to change my release numbering system from a.b.c[.d] to a.b.c-d, but I suspect that move would cause disruption to all of the distro maintainers (and some amount of work for me). -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
