I've received an updated Chinese translation (simplified and traditional) based on 1.0 and we've got the popfile.pck bug. Anything else that would be worth packaging together as a 1.1 release?
John.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The cross-platform ZIP package for 1.0.0 does not include the Brazilian Portuguese language file for the UI, probably because the Makefile needs to take into account the fact that the filename contains a space (engine/languages/Portugues do Brasil.msg)
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I've got your CVS changes. Now I'll need to update the installer to work with the new filename, create a new SSL Patch Control File, update CVS, upload the Patch Control File and update the MD5SUMS file. I'll do this later this evening.
I'm assuming "1.1" means "1.1.0" and not "1.0.1" (the SSL Patch Control File's name includes the POPFile release number).
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> Now I'll need to update the installer to work with the new filename, create a new SSL Patch Control File, update CVS, upload the Patch Control File and update the MD5SUMS file. <<
CVS now has all of my changes, the new Patch Control File has been uploaded and the MD5SUMS file updated.
I've assumed "1.1.0" but this can easily be changed to "1.0.1" if you prefer.
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Seems to me we should drop the last digit if we are going to release such a minor change as 1.1.0 (making this just 1.1). That last digit is misleading, indicating there can be a more minor release than this, since this is mostly a language file update you can't get much more minor. Basing the versioning system on what we have been doing, this should be 1.0.1. We released 0.22.x versions for years because there was not much difference between releases. There are benefits to advancing the version number quickly, but if we are going to start doing that, we need to drop the last digit of the version so such minor changes don't look like major updates.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I've made a new Patch Control File, added it to CVS, uploaded it to the server and updated the MD5SUMS file. So you can use either 1.0.1 or 1.1.0 for the next release.
I'll update the installer source code comments and remove the redundant Patch Control File once a final decision has been taken on the version numbering scheme.
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> Seems to me we should drop the last digit ... That last digit is misleading, indicating there can be a more minor release than this, since this is mostly a language file update you can't get much more minor ... we need to drop the last digit of the version so such minor changes don't look like major updates. <<
I think we should retain the last digit, i.e. use x.y.z instead of simply x.y for future releases.
I have quite a long "To Do" list for the installer and would like to be able to update the installer even if the rest of POPFile does not change. The last digit could be used to indicate that only the installer has been updated.
For example,
cross-platform package v1.1.0
Windows package v1.1.0
Windows package v1.1.1
Windows package v1.1.2
could all install the same version of POPFile (as far as the Perl code etc is concerned).
The v1.0.0 Windows package would be released at the same time as the cross-platform one.
The v1.1.1 and v1.1.2 Windows packages would install the same files as the cross-platform 1.1.0 package but with better support for Windows (e.g. improved handling of upgrades, better support for limited user accounts, etc).
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry to barge in here - does the "updated SSL patch control file" have anything to do with the issues I had downloading SSL support in my forum post (http://sourceforge.net/forum/forum.php?thread_id=1910771&forum_id=213100)? Known issue?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> does the "updated SSL patch control file" have anything to do with the issues I had downloading SSL support <<
No, it has nothing to do with the 1.0.0 installer.
There is a separate SSL patch control file for each release (e.g. the 0.22.5 installer downloads a file called 0.22.5.pcf and the 1.0.0 installer downloads a file called 1.0.0.pcf).
I will respond to your SSL problem in the other thread.
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A user has reported that very long (>25000 bytes) From, To or Cc headers
cause POPFile v1 to crash in Nihongo mode.
This is a problem not in v0.22.5 but in v1.0.0.
My change to remove invalid characters as euc-jp from headers seems to
cause this problem.
Now I'm working to avoid the problem. I've built a workaround code for
the user to test.
I want to fix this bug until 1.0.1 release.
Naoki
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> Brian: I saw a commit or two from you. Are you done with your installer changes for 1.0.1? <<
Those changes fixed the complaint from someone that the installer did not recommend upgrading the SSL support files when an existing installation was upgraded.
I have started looking at what I need to do to reduce the number of dialogue boxes displayed when upgrading.
This is not a quick fix and I'm not sure how long it will take me. This is a "nice to have" feature so I do not think it is worth delaying the 1.0.1 release for it.
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> anyone object if we take the current branch and package a 1.0.1? <<
No, I think we are ready for 1.0.1 now.
A word of warning though: have you upgraded to PDK 7.1 yet?
I have just upgraded and found that although the installation guide says
"You can install the Perl Dev Kit on Microsoft Windows Server 2003, Windows XP, Windows 2000, Windows NT 4, Windows Me, or Windows 98 operating systems."
the release notes say
"Changed System Requirements
The Windows release of PDK 7.1 now requires Windows 2000 or later. Earlier Windows versions may continue to work for now, but are no longer supported."
When I upgraded from PDK 7.0 to 7.1 on my Win98SE system I found that the PerlTray "sample" project no longer runs. It compiles OK but when I run it nothing appears in the system tray and Windows says the program has stopped responding.
Building that sample using PDK 7.1 on my Vista system still produces something that won't run on Win98SE.
So far that is the only thing I've tried to do with PDK 7.1.
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The PDK is used to build popfile.exe, popfileb.exe, popfilef.exe, popfileib.exe, and popfileif.exe (plus popfile-service.exe which is not supported by Win9x).
If PDK 7.1 no longer builds programs that work on Win9x then we can still support Win9x by using alternative programs for those systems.
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So does that mean it still runs fine for now including the trayicon or only without the trayicon? If it is going to run on 98 with no trayicon, we need to mention that in the release notes. Providing old EXEs for 98 would work for now since the old builds will work, but once we release 2.0 builds we won't have working EXEs. Am I right?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> So does that mean it still runs fine for now including the trayicon or only without the trayicon? <<
I have no idea yet because all I have done is uninstall PDK 7.0, install PDK 7.1 and try the PerlTray sample supplied with the PDK.
>> Providing old EXEs for 98 would work for now since the old builds will work, but once we release 2.0 builds we won't have working EXEs. Am I right? <<
We could use PDK 7.0 to build Win9x-compatible EXEs (or even use NSIS to do this though a replacement for the system tray icon may not be possible).
2.0.0 has significantly different Perl requirements and if we switch to Perl 5.10 for 2.0.0 then Win9x support may become more difficult.
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are getting to the point where supporting 98 is not a necessity. Anyone still using 98 isn't that likely to upgrade PF and we haven't had any major issues or security problems that mean that couldn't keep with PF 1.0.x.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've received an updated Chinese translation (simplified and traditional) based on 1.0 and we've got the popfile.pck bug. Anything else that would be worth packaging together as a 1.1 release?
John.
The cross-platform ZIP package for 1.0.0 does not include the Brazilian Portuguese language file for the UI, probably because the Makefile needs to take into account the fact that the filename contains a space (engine/languages/Portugues do Brasil.msg)
Brian
Now that's weird. I long ago fixed that bug, but I guess it got reintroduced. Seems like a nice small thing to get into 1.1.
John.
OK, I've got your CVS changes. Now I'll need to update the installer to work with the new filename, create a new SSL Patch Control File, update CVS, upload the Patch Control File and update the MD5SUMS file. I'll do this later this evening.
I'm assuming "1.1" means "1.1.0" and not "1.0.1" (the SSL Patch Control File's name includes the POPFile release number).
Brian
>> Now I'll need to update the installer to work with the new filename, create a new SSL Patch Control File, update CVS, upload the Patch Control File and update the MD5SUMS file. <<
CVS now has all of my changes, the new Patch Control File has been uploaded and the MD5SUMS file updated.
I've assumed "1.1.0" but this can easily be changed to "1.0.1" if you prefer.
Brian
1.1.0 is correct.
Anyone else got things that they want to squeeze into this release?
John.
Seems to me we should drop the last digit if we are going to release such a minor change as 1.1.0 (making this just 1.1). That last digit is misleading, indicating there can be a more minor release than this, since this is mostly a language file update you can't get much more minor. Basing the versioning system on what we have been doing, this should be 1.0.1. We released 0.22.x versions for years because there was not much difference between releases. There are benefits to advancing the version number quickly, but if we are going to start doing that, we need to drop the last digit of the version so such minor changes don't look like major updates.
Point well taken. This should be 1.0.1, you are correct that it's really minor.
John.
>> This should be 1.0.1 <<
OK, I've made a new Patch Control File, added it to CVS, uploaded it to the server and updated the MD5SUMS file. So you can use either 1.0.1 or 1.1.0 for the next release.
I'll update the installer source code comments and remove the redundant Patch Control File once a final decision has been taken on the version numbering scheme.
Brian
>> Seems to me we should drop the last digit ... That last digit is misleading, indicating there can be a more minor release than this, since this is mostly a language file update you can't get much more minor ... we need to drop the last digit of the version so such minor changes don't look like major updates. <<
I think we should retain the last digit, i.e. use x.y.z instead of simply x.y for future releases.
I have quite a long "To Do" list for the installer and would like to be able to update the installer even if the rest of POPFile does not change. The last digit could be used to indicate that only the installer has been updated.
For example,
cross-platform package v1.1.0
Windows package v1.1.0
Windows package v1.1.1
Windows package v1.1.2
could all install the same version of POPFile (as far as the Perl code etc is concerned).
The v1.0.0 Windows package would be released at the same time as the cross-platform one.
The v1.1.1 and v1.1.2 Windows packages would install the same files as the cross-platform 1.1.0 package but with better support for Windows (e.g. improved handling of upgrades, better support for limited user accounts, etc).
Brian
>> The v1.0.0 Windows package ... <<
Oops! I meant to say "The v1.1.0 Windows package"
Brian
We should keep all three digits, but I'm not in favour of having different numbers for both versions. I'd rather keep things in sync. for simplicity.
John.
Sorry to barge in here - does the "updated SSL patch control file" have anything to do with the issues I had downloading SSL support in my forum post (http://sourceforge.net/forum/forum.php?thread_id=1910771&forum_id=213100)? Known issue?
>> does the "updated SSL patch control file" have anything to do with the issues I had downloading SSL support <<
No, it has nothing to do with the 1.0.0 installer.
There is a separate SSL patch control file for each release (e.g. the 0.22.5 installer downloads a file called 0.22.5.pcf and the 1.0.0 installer downloads a file called 1.0.0.pcf).
I will respond to your SSL problem in the other thread.
Brian
A user has reported that very long (>25000 bytes) From, To or Cc headers
cause POPFile v1 to crash in Nihongo mode.
This is a problem not in v0.22.5 but in v1.0.0.
My change to remove invalid characters as euc-jp from headers seems to
cause this problem.
Now I'm working to avoid the problem. I've built a workaround code for
the user to test.
I want to fix this bug until 1.0.1 release.
Naoki
I've solved this problem and committed the patch to CVS.
Naoki
Great. Thanks.
Brian: I saw a commit or two from you. Are you done with your installer changes for 1.0.1?
John.
>> Brian: I saw a commit or two from you. Are you done with your installer changes for 1.0.1? <<
Those changes fixed the complaint from someone that the installer did not recommend upgrading the SSL support files when an existing installation was upgraded.
I have started looking at what I need to do to reduce the number of dialogue boxes displayed when upgrading.
This is not a quick fix and I'm not sure how long it will take me. This is a "nice to have" feature so I do not think it is worth delaying the 1.0.1 release for it.
Brian
OK, given that anyone object if we take the current branch and package a 1.0.1?
John.
>> anyone object if we take the current branch and package a 1.0.1? <<
No, I think we are ready for 1.0.1 now.
A word of warning though: have you upgraded to PDK 7.1 yet?
I have just upgraded and found that although the installation guide says
"You can install the Perl Dev Kit on Microsoft Windows Server 2003, Windows XP, Windows 2000, Windows NT 4, Windows Me, or Windows 98 operating systems."
the release notes say
"Changed System Requirements
The Windows release of PDK 7.1 now requires Windows 2000 or later. Earlier Windows versions may continue to work for now, but are no longer supported."
When I upgraded from PDK 7.0 to 7.1 on my Win98SE system I found that the PerlTray "sample" project no longer runs. It compiles OK but when I run it nothing appears in the system tray and Windows says the program has stopped responding.
Building that sample using PDK 7.1 on my Vista system still produces something that won't run on Win98SE.
So far that is the only thing I've tried to do with PDK 7.1.
Brian
I don't think we want to drop support for 98. But if loosing the trayicon is the only issue, that isn't bad.
The PDK is used to build popfile.exe, popfileb.exe, popfilef.exe, popfileib.exe, and popfileif.exe (plus popfile-service.exe which is not supported by Win9x).
If PDK 7.1 no longer builds programs that work on Win9x then we can still support Win9x by using alternative programs for those systems.
Brian
So does that mean it still runs fine for now including the trayicon or only without the trayicon? If it is going to run on 98 with no trayicon, we need to mention that in the release notes. Providing old EXEs for 98 would work for now since the old builds will work, but once we release 2.0 builds we won't have working EXEs. Am I right?
>> So does that mean it still runs fine for now including the trayicon or only without the trayicon? <<
I have no idea yet because all I have done is uninstall PDK 7.0, install PDK 7.1 and try the PerlTray sample supplied with the PDK.
>> Providing old EXEs for 98 would work for now since the old builds will work, but once we release 2.0 builds we won't have working EXEs. Am I right? <<
We could use PDK 7.0 to build Win9x-compatible EXEs (or even use NSIS to do this though a replacement for the system tray icon may not be possible).
2.0.0 has significantly different Perl requirements and if we switch to Perl 5.10 for 2.0.0 then Win9x support may become more difficult.
Brian
We are getting to the point where supporting 98 is not a necessity. Anyone still using 98 isn't that likely to upgrade PF and we haven't had any major issues or security problems that mean that couldn't keep with PF 1.0.x.