A reminder since I neglected it the last time: The next release of Debian will be frozen on 5 November 23:59 UTC [1]. Any new versions must make it to testing before that, i.e. be uploaded before 26 October. If you wish to make another stable Pike release and have it be included in jessie, now is the time to start finalizing it.
Excerpts from Magnus Holmgren, Millnet/Lysator/Debian/Mensa @ Pike developers forum's message of 2014-09-28 23:30:02 +0200:
A reminder since I neglected it the last time: The next release of Debian will be frozen on 5 November 23:59 UTC [1]. Any new versions must make it to testing before that, i.e. be uploaded before 26 October. If you wish to make another stable Pike release and have it be included in jessie, now is the time to start finalizing it.
what is the version currently available for debian?
greetings, martin.
On Mon, Sep 29, 2014 at 12:02 PM, Martin Bähr mbaehr@email.archlab.tuwien.ac.at wrote:
what is the version currently available for debian?
greetings, martin.
7.8.866
ChrisA
What do we need to make a 8.0 release this week, even if it is only for Debian?
What do we need to make a 8.0 release this week, even if it is only for Debian?
Left on my TODO-list for 8.0 is supporting the set_buffer_mode() API in SSL.File (both for the SSL.File itself, and being set on the supplied socket), but it can probably be left out in an initial release.
I can't promise that Pike 8.0 will make it into Debian 8.0. Since it will be a new set of packages it will have to make it through the NEW queue before the freeze.
Since it's not completely new software it's possible that I can prod a bit so that it can make it through in less than a week, like in the case of a single new binary package.
If it does get in, should it be the default version, i.e. have higher priority in the alternatives system than pike7.8? (I've planned to make a pike-defaults package similar to python-defaults, but that hasn't happened yet.)
If it does get in, should it be the default version, i.e. have higher priority in the alternatives system than pike7.8? (I've planned to make a pike-defaults package similar to python-defaults, but that hasn't happened yet.)
As Pike 8.0 has been stablizing since the fork from 7.9 11 months ago, and has multiple advantages over 7.8, I believe the reasonable default is Pike 8.0.
Calling it "stabilizing" is not really honest. There's been a steady flow of substantial core changes up until very recently, e.g. in SSL, Stdio.File based on String.Buffer, the x86_64 JIT, preprocessor etc. That doesn't mean it's not a good default choice, but let's not kid ourselves that the feature set was frozen 11 months ago.
The release process seems a bit backward IMHO. Why did 7.9 become 8.0 in the first place if it wasn't meant to be feature frozen?
Also, shouldn't there be a "master" git branch where development takes place? When it's time for feature freeze in preparation for a release, a release branch (say 8.2) would be forked and reserved for bugfixes. New features would be pushed/merged to "master". Adopting this workflow would at this point be as easy as renaming the branch "8.1" to "master". :-)
There is no need for the branch to be called "master" for the workflow to work. HEAD points to 8.1, so this is what you get if you clone without specifying a branch.
There is no need for the branch to be called "master" for the workflow to work. HEAD points to 8.1, so this is what you get if you clone without specifying a branch.
Sure, but what's the point of these in-between unstable versions really? Isn't it just a legacy workflow inherited from the CVS days?
If somebody's developing a new feature on the 8.1 branch, and 8.1 becomes 8.2, where do they push their commits? Sure, 8.2 can be forked to 8.3, but then people would need to rename branches locally, rebase their feature branches and whatnot. If feature development could always be based on a single, non-renaming, development branch, wouldn't that reduce hassle?
(Admittedly, branches aren't renamed that often, but still -- we're engineers, why not reduce unnecessary work where possible? ;) )
When 8.1 becomes 8.2 and 8.3, people developing on 8.1 will need to choose whether to continue their work in 8.2 or 8.3. This is intentional. Local branches need to be rebased before push anyway, only the upstream branch config needs to be changed as a result of the split. I don't think a "git branch --set-upstream" every other year or so is that much of a hassle... OTOH it is good to be aware that a split has happened and to think about which line is suitable for your continued work.
Alright.
Anyways, the biggest point of my original comment was that moving 7.9 to 8.0 was rather pointless at the time, since it didn't imply a feature freeze. But, as always, the feature freeze can be handled out-of-band, which is also what happened the other week.
Yup, even numbered branches are supposed to be feature frozen, so if that hasn't happened it's a lack of dicipline which will probably not be fixed by changing the names of the branches.
I agree that the 7.9 to 8.0 wasn't doen right. HEAD should have moved from 7.9 to 8.1.
Jonas Walld?n @ Pike developers forum wrote:
Calling it "stabilizing" is not really honest. There's been a steady flow of substantial core changes up until very recently, e.g. in SSL, Stdio.File based on String.Buffer, the x86_64 JIT, preprocessor etc. That doesn't mean it's not a good default choice, but let's not kid ourselves that the feature set was frozen 11 months ago.
All true. But given the release cycles of Debian, it's better to get 8.0 as the default now, and simply squash any stability issues with an 8.0.xxx during the debian release process. All things considered, 8.0 works quite well for me in production; better than 7.8.
pike-devel@lists.lysator.liu.se
-
Chris Angelico -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Jonas Walld�n ＠ Pike developers forum
-
Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Bähr -
Martin Karlgren (arga kodarn) ＠ Pike (-) developers forum
-
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum
-
Stephen R. van den Berg