On Wed, 11 Mar 2020 at 13:30, Larry Shaffer <[email protected]> wrote:
> Need some clarification on some particulars related to versioning and > releases... > > Do you mean minor instead of major releases? You speak of reverting a feature > prior to a *major* release, but features are introduced on master prior to > every 4-month (minor or major) release, as indicated by your footnote for > 3.14. Yep, sorry. I meant 3.14 as opposed to 4.0 > "This extends from when the feature is merged into a development branch until > its public QGIS release containing the feature." Sounds much nicer :) > Also ... > >> - After this major release, the developer is still expected to monitor >> the bug tracker for issues relating to their work and implement >> reasonable fixes at their own expense. >> " > > > Like... forever? What about the *value* of their contribution to the project > itself? Something highly variable and relative, even for core features. And > what about later, when the feature is stable, but needs refactored to meet > other changes in the codebase? Does that then constitute a 'bug'? > > Maybe instead: > > "After the first public QGIS release containing the feature and until the > next public release (or whatever interval is agreed upon), the developer is > still expected to monitor the bug tracker for issues relating to their work > and implement reasonable fixes at their own expense." > > I'd be hard pressed to convince any funding backers that they need to pay me > to develop a feature and financially support it in perpetuity, especially if > the feature also benefits the project/app and its users. However, it seems > reasonable to say to a customer "and you also need to support the fixing of > this feature's bugs found by the public until the following public release." That sounds ok to me. > I'm all for accountability in code maintenance, but there has to be a limit. > Otherwise, contributions may become viewed as indentured servitude. Ha. I'm sure the handful of current regular maintainers already feel like we're slaves to all this abandoned code that other people are pushing into master... And to be blunt, I'd rather these other contributors/sponsors feel this pressure than us! Nyall _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
