On Wed, Apr 22, 2015 at 5:48 AM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > Where was the discussion on this? I couldn't find it anywhere in > jenkins.2015-01-07-19.01.log.html or jenkins.2015-01-21-19.01.log.html
Not sure why you are looking at logs in January! According to https://wiki.jenkins-ci.org/display/JENKINS/LTS+Release+Line the next baseline is picked around the time 1.596.3 is released. The RC was posted on Apr 05, meaning the release should have been on Apr 19/20. Clearly that did not happen; maybe Kohsuke just forgot? Picking a baseline generally happens during a project meeting, which is not for another week, though I suppose it could be done on the dev list as well. > /me hoping for 1.607+ or 1.610 ideally /me hoping for 1.607+ definitely, or 1.609+ ideally, and if not 1.610+ then I certainly have some `lts-candidate`s I will push for. I have complained about this to Kohsuke privately but perhaps others are affected too: it would be really helpful if the upcoming LTS baseline were decided (*) well in advance, so that people writing APIs would know when those changes would actually be available for use from plugins with LTS dependencies (as is usually preferred). As it stands, for workflow-plugin I have the master branch on 1.596.x, a branch using APIs from 1.599+ intended for the next LTS, a branch on top of that branch (!) using 1.609+ which may or may not be in the next LTS, and an unrelated branch using 1.607+ which will probably be in the next LTS but I am not sure. I cannot collapse these branches without running the risk that the LTS will be earlier than 1.609 and I will have to revert some of my changes and put them back in a branch. It would be a lot less work, and merge conflicts, if I knew in advance what I was going to get in May, and could plan accordingly. Indeed my core changes could be planned with a schedule in mind, and reviewers could ask for a particularly dangerous-looking PR to be put on hold if a new baseline were imminent. Put another way, the current policy is fine if you think of Jenkins core releases as more or less equivalent, but some more stable than others according to a couple dozen user ratings, so we might as well pick a reasonably recent sunny one so fewer regression fixes need to be backported. It does not work when you think of core as a platform with APIs that plugin authors are awaiting the delivery of. I realize that most plugins use rather old core dependencies and are not much affected, so perhaps mine is a minority complaint. (*) Since we seem to have replaced the RC system with a policy of doing multiple 1.xxx releases in a week if warranted, the decision would be better stated in terms of a date, rather than a version number. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2paJyCam8YCcSn8TZ-vZzdmghLMLBOpcHYjYbbKtr%2Brg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
