PATH handling needs to be removed from 2.3-based installers also
Right now 2.3.18 installers truncate system PATH if it is long, as discussed in this Trac ticket.
@selvanair, @chipitsine : I will backport PR https://github.com/OpenVPN/openvpn-build/pull/105 to release/2.3 branch in openvpn-build, plus upgrade to the easy-rsa version which has the PATH problem fixed. Let me know if you have concerns regarding this: I'd like to get fixed installers out next Monday.
@mattock, will you also use modern nsis? 2.51 ?
I had a look at track ticket. People use 2.3 on win7. I think we should modify installer and warn people to use 2.4 if OS is Vista or higher
Back-porting the 2.4 patch for removing PATH modification to the release/2.3 branch makes sense. Else we'll have to maintain two versions of nsis binary and switch to the patched one for building 2.3.
When doing test compilation I just use the master branch and change the source tarball and do not build the installer -- so hadn't realized that we're still modifying PATH in 2.3 installers.
@chipitsine : Do you mean that no point in updating 2.3 instead of moving to 2.4 unless constrained by the OS (i.e pre Vista)? I too wonder why Vista+ folks continue to update 2.3 when 2.4 is available.
@selvanair , I beleive that windows 10 in trac#948 was used in purpose. however, I think people still can use 2.3 on modern OS (for reasons I do not understand), we should warn them and suggest to install 2.4
@chipitsine : both 2.3 and 2.4 installers are and will be built with the same NSIS version (2.51) on the same build computer.
Afaik 2.3 runs just fine on Windows 10. Even "block-outside-dns" has been backported to 2.3.
@mattock, I meant that people may use 2.3 because they, for example were using 2.3.10 and they noticed "new" 2.3.18 (but they can upgrade to 2.4)
I mean something like that https://github.com/chipitsine/openvpn-build/commit/538edc5c2f711099357f82ef50336c1da94d33bc
I think this "nag screen" would be a good topic for a community meeting. In fact, this could be discussed on a more generic level:
- Do we (really) want to maintain each release for two release cycles?
- If not, maybe drop support for "oldstable" after <n> point releases of the current "stable"?
- If we're not ok with dropping oldstable support entirely, we could move it to "source-only" maintenance mode.
So, we can even include something like "this 2.3 installer is not actively maintained anymore"?
issue is for release/2.3 which is long obsolete