Hi Alan, Arran et al, Given that v4.0.x has been thrown on the floor and will be rewritten from ground up(and it won't know about RADSEC et al for a while), is it sensible to do a 3.1.x point release at some point so we have something to move to that includes some under-the-hood improvements compared to v3.0.12? Just a question... Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On Oct 27, 2016, at 9:04 AM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
Given that v4.0.x has been thrown on the floor and will be rewritten from ground up
Not entirely... the modules will stay the same. The unlang code will stay the same. I'm just re-writing the networking / threading layer.
(and it won't know about RADSEC et al for a while), is it sensible to do a 3.1.x point release at some point so we have something to move to that includes some under-the-hood improvements compared to v3.0.12?
At this point, if you need the features in v3.1., just use the v3.1.x branch. It's stable, and used by many people in production. The only advantage to a "blessed" release is that it goes into OS distributions. The disadvantage of a blessed release is that it goes into OS distributions for years and years and years and years, and doesn't get upgraded. Ever. We just don't have time / bandwidth to support people using v2, v3, v3.1, and v4 all at the same time. Especially because the OS vendors have made it clear they just don't give a shit about their customers, and refuse to (a) upgrade to a recent release, or (b) support their own paying customers. If the OS vendors upgraded in a timely fashion, it would be easier to do v3.1. But it would still be difficult, and we'd probably still skip 3.1. Alan DeKok.
At this point, if you need the features in v3.1., just use the v3.1.x branch. It's stable, and used by many people in production.
There are still regular checkins... This bugs our dev :-)
The only advantage to a "blessed" release is that it goes into OS distributions. The disadvantage of a blessed release is that it goes into OS distributions for years and years and years and years, and doesn't get upgraded. Ever.
So if we were to choose a specific Github commit, we should be ok. The blessed release also gives someone paranoid enough about this reassurance that that release is stable enough to go with it.
We just don't have time / bandwidth to support people using v2, v3, v3.1, and v4 all at the same time. Especially because the OS vendors have made it clear they just don't give a shit about their customers, and refuse to (a) upgrade to a recent release, or (b) support their own paying customers.
Fair enough, I understand. I've had a moan at a certain distribution's folks today about this.
If the OS vendors upgraded in a timely fashion, it would be easier to do v3.1. But it would still be difficult, and we'd probably still skip 3.1.
Ok... I'll suggest to our dev that we pick a commit and release that. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On Oct 27, 2016, at 10:01 AM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
At this point, if you need the features in v3.1., just use the v3.1.x branch. It's stable, and used by many people in production.
There are still regular checkins... This bugs our dev :-)
Well, 3.0 has checkins, too. v3.1.x is feature frozen. The only checkins are bug fixes pulled over from v3 or v4.
So if we were to choose a specific Github commit, we should be ok. The blessed release also gives someone paranoid enough about this reassurance that that release is stable enough to go with it.
Yes. Alan DeKok.
On Thu, Oct 27, 2016 at 02:01:00PM +0000, Stefan Paetow wrote:
At this point, if you need the features in v3.1., just use the v3.1.x branch. It's stable, and used by many people in production.
There are still regular checkins... This bugs our dev :-)
Sounds like your problem then :)
So if we were to choose a specific Github commit, we should be ok. The blessed release also gives someone paranoid enough about this reassurance that that release is stable enough to go with it.
TBH, I do that with 3.0.x as well anyway. No software is perfect. "Releases" are just a thing to make people who don't understand think they're getting something more stable. There are still bugs. I'd just pick a commit and run with it, then you can cherry-pick any future bugfixes if you need them. I *think* there's still an issue with EAP-TLS on Windows with 3.1? Haven't had time to look at it for a while. Stability is still to be found in 3.0. :) Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Oct 27, 2016, at 10:24 AM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Thu, Oct 27, 2016 at 02:01:00PM +0000, Stefan Paetow wrote:
At this point, if you need the features in v3.1., just use the v3.1.x branch. It's stable, and used by many people in production.
There are still regular checkins... This bugs our dev :-)
Sounds like your problem then :)
So if we were to choose a specific Github commit, we should be ok. The blessed release also gives someone paranoid enough about this reassurance that that release is stable enough to go with it.
TBH, I do that with 3.0.x as well anyway.
No software is perfect. "Releases" are just a thing to make people who don't understand think they're getting something more stable. There are still bugs.
I'd just pick a commit and run with it, then you can cherry-pick any future bugfixes if you need them.
I *think* there's still an issue with EAP-TLS on Windows with 3.1? Haven't had time to look at it for a while. Stability is still to be found in 3.0. :)
I think it's only weird ones where you're combining EAP-TLS and PEAP, and I think it's broken in v3.0.x as well. I... I guess you could say "fixed" but it wasn't really broken... Um, changed the fragmentation behaviour back to v3.0.x style in v3.1.x. -Arran
On Thu, Oct 27, 2016 at 12:07:49PM -0400, Arran Cudbard-Bell wrote:
I *think* there's still an issue with EAP-TLS on Windows with 3.1? Haven't had time to look at it for a while. Stability is still to be found in 3.0. :)
I think it's only weird ones where you're combining EAP-TLS and PEAP, and I think it's broken in v3.0.x as well.
Ah - maybe it was PEAP/EAP-TLS. Using that here (I'm a "weird one"!), which is probably why I remember it being an issue. PEAP/EAP-TLS is working fine here on 3.0.x. I had two servers one on 3.0.x and the other on 3.1. But at some point moved them both to 3.0.x when I upgraded the OS as I already had packages built.
I... I guess you could say "fixed" but it wasn't really broken... Um, changed the fragmentation behaviour back to v3.0.x style in v3.1.x.
Ah, I see 6e37f0f4d373c99631965a46ea6161a9d2c38572... hadn't noticed that. So rather than making wild guesses I suppose I should really be useful and just try 3.1.x again and see if it's OK now... :) Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Matthew Newton -
Stefan Paetow