Looking way ahead, here's an idea for how 5.1 releases could work:
New point releases (5.1.1 etc) would be monthly except in emergencies. Beta releases would fill the weeks between and provide quick access to fixes. Customers would have a choice of setting their site to cutting edge mode (beta updates) or stable mode (point releases). No new fixes implemented (just fixes of fixes) between last beta and point release.
Seems like that could address the complains I get from people who say there are too many updates, and enable even faster fix releases in beta form. Or, on the other hand, it could just delay most people from getting important fixes for a month. What do you think?
I'm also building a few automated test cases to catch the most obvious mistakes, like parse errors on the submit link page.
Although I hate having so many upgrades, I would hate even more to miss an important fix. Stuck between the devil and the deep blue sea!
I myself would just prefer a stable program that doesn't keep evolving. This script is brilliant and really does more than I want (and I am very difficult to please )
On my case I believe that the script already has a great amount of features and in my case it also has more features than the ones I use. What I do not like is the feeling that we never have a really stable non bug version to stand on.
So my suggestion would be to spend the encesary time to check most of the features, make shure they are working correctly and correct the existing bugs. Then, releasing this stable version from were we start. Afer this version new features can be implemented.
Ths script has a tremendous potential but I feel frustrated due to not having the possibility of exploding it because of the bugs.
peumus wrote: What I do not like is the feeling that we never have a really stable non bug version to stand on.
So my suggestion would be to spend the encesary time to check most of the features, make shure they are working correctly and correct the existing bugs. Then, releasing this stable version from were we start. Afer this version new features can be implemented.
Ths script has a tremendous potential but I feel frustrated due to not having the possibility of exploding it because of the bugs.
Could not agree more. It is also the reason why I have not pushed the affiliate program at all.
In a perfect world, there'd be no new features within a series. In this world, new features implemented in the middle of a series are an absolute necessity when people pay for them, because the script wouldn't exist without that revenue. I'll try to cut back or eliminate unpaid new features in-series though.
With millions of possible combinations of settings in addition to various server configurations, however, I can't see any way to test them all.
The ironic thing is both of you have new feature requests you're waiting on.
My aim is to be honest in order to let you realize what I see it's happening and that does not allow us to progress.
I believe that I have spend almost 80% of the time I devote to my sites in trying to understand were the bugs come from, this since I joined (take a look at the year) but now I really do not have the time nor the strenght to invest so much time on this process. I want to use the script on a professional way for sites to make some money so I need the script to work seriously, this is why I really need not bugs.
The basic difficulty are not the new features but the misfunctions. At the moment almost every upgrade carries misfunctions and some features that were working before stops working on the upgrade. This is why I do not like to upgrade and I do it only when other people has already reported the bugs...this shall be happening to other people too delaying their upgrades.
Some more ideas that you can take:
- We can have versions as 5.aa.bb in were aa means a new feature is included in the version, but bb means just a bug correction, so we can know what version we are upgrading to.
- You shall have a check list to test most of the common features after a new version is liberated (maybe this process can be automated).
- Maybe there's something that can be done on the structure of the code to isolate the current funcions from the new ones in order to reduce misfuncions when implementing new features or when upgrading.
- On the same way as you already have wsnforum implemented on philosophyforums.com you shall have a public site in were wsnlinks is implemented with all their features. This will give you a real feeling of what's happening.
Paul wrote: In a perfect world, there'd be no new features within a series. In this world, new features implemented in the middle of a series are an absolute necessity when people pay for them, because the script wouldn't exist without that revenue. I'll try to cut back or eliminate unpaid new features in-series though.
With millions of possible combinations of settings in addition to various server configurations, however, I can't see any way to test them all.
I can fully understand that BUT it is the frequency of the upgrades. Like Daniel I am spending the majority of my time just upgrading. For instance, this month there have been 5 upgrades, December 4, November 5, October 5, September 8. When you have a number of sites running on the script it's a real pain.
Now you say that I may have to redo all my templates again when you release v.5.1 When you have a number of sites running the script and they all have highly customised templates that were only completely rewritten a year ago due to upgrading to 5, it gets rather time consuming to say the least.
Paul wrote: The ironic thing is both of you have new feature requests you're waiting on.
I have? The only thing I can remember is concerning copying the setup, but that is not new as it was always there until a recent version when you removed it.
pemeus wrote: The basic difficulty are not the new features but the misfunctions.
The new features are what usually cause the misfunctions, of course. Feature x that worked in the 4.1 series stops working in 5.0 because of new feature y, and so on. Though sometimes a fix to one thing breaks another.
A longer time between releases would help address this problem, but I'm not sure if people want that more than they want a quick fix. I'll try out posting more of the quick fixes to the forum for manual application.
you shall have a public site in were wsnlinks is implemented with all their features.
I've got tons of them, from the customer downloads area to links.webmastersite.net.
I'll consider your versioning suggestion. That'd essentially abolish the current notion of series in favor of just major version numbers and feature releases, I guess. Problem is it could lead to having to maintain 20 different supported versions, which is unrealistic.
babrees wrote: I have? The only thing I can remember is concerning copying the setup, but that is not new as it was always there until a recent version when you removed it.
It's new. What used to be visibly linked -- and is still there, as I explained, if you visit it manually -- isn't what you actually want.
When you have a number of sites running on the script it's a real pain.
I have around 30 WSN installations. I don't bother applying all upgrades to most of them (in fact, a few are still on the 4.1 series). Why should I? When there's something important that I want all to have, I use the multisite updater and it takes a couple minutes.
Now you say that I may have to redo all my templates again when you release v.5.1
I said I don't have a clue how different 5.1's templates will be. Do you want me to lie? I also said I intend them to be as indifferent as possible, so what do you expect?
The 4.1 -> 5.0 upgrade didn't require starting templates from scratch. It adjusted what it could and gave instructions for the rest. If you make extreme changes then that can take a long time, but you need to reconsider your changes in that case.
It took me maybe a couple of hours to upgrade simplicity and aquatic from 4.1 to 5.0.
Also, just because I release 5.1 doesn't mean you have to immediately use it. I'm sure 5.0 will be supported into 2010.
At any rate, new development is a necessity for survival. I need to complete a software directory and ratings edition this year, and to be manageable all the scripts need to share the same code base.
Due to the big problems for apache mode people and people of limited memory in the last few releases, I'm introducing betas right away. 5.0.42 will add support so that 5.0.43 will be first released as a beta. The duration of the beta period won't be fixed as described in the opening post, though.
0/5
1
2
3
4
5
Sorry, you don't have permission to post posts. Log in, or register if you haven't yet.
Comments on Future release schedules
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7867
Looking way ahead, here's an idea for how 5.1 releases could work:
New point releases (5.1.1 etc) would be monthly except in emergencies. Beta releases would fill the weeks between and provide quick access to fixes. Customers would have a choice of setting their site to cutting edge mode (beta updates) or stable mode (point releases). No new fixes implemented (just fixes of fixes) between last beta and point release.
Seems like that could address the complains I get from people who say there are too many updates, and enable even faster fix releases in beta form. Or, on the other hand, it could just delay most people from getting important fixes for a month. What do you think?
I'm also building a few automated test cases to catch the most obvious mistakes, like parse errors on the submit link page.
Expert
Usergroup: Customer
Joined: Aug 19, 2005
Location: England
Total Topics: 391
Total Comments: 1303
hmm, difficult one this.
Although I hate having so many upgrades, I would hate even more to miss an important fix. Stuck between the devil and the deep blue sea!
I myself would just prefer a stable program that doesn't keep evolving. This script is brilliant and really does more than I want (and I am very difficult to please
Forum Regular
Usergroup: Customer
Joined: Aug 09, 2004
Location: Chile
Total Topics: 172
Total Comments: 462
On my case I believe that the script already has a great amount of features and in my case it also has more features than the ones I use. What I do not like is the feeling that we never have a really stable non bug version to stand on.
So my suggestion would be to spend the encesary time to check most of the features, make shure they are working correctly and correct the existing bugs. Then, releasing this stable version from were we start. Afer this version new features can be implemented.
Ths script has a tremendous potential but I feel frustrated due to not having the possibility of exploding it because of the bugs.
Thanks,
Daniel.
Expert
Usergroup: Customer
Joined: Aug 19, 2005
Location: England
Total Topics: 391
Total Comments: 1303
What I do not like is the feeling that we never have a really stable non bug version to stand on.
So my suggestion would be to spend the encesary time to check most of the features, make shure they are working correctly and correct the existing bugs. Then, releasing this stable version from were we start. Afer this version new features can be implemented.
Ths script has a tremendous potential but I feel frustrated due to not having the possibility of exploding it because of the bugs.
Could not agree more. It is also the reason why I have not pushed the affiliate program at all.
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7867
In a perfect world, there'd be no new features within a series. In this world, new features implemented in the middle of a series are an absolute necessity when people pay for them, because the script wouldn't exist without that revenue. I'll try to cut back or eliminate unpaid new features in-series though.
With millions of possible combinations of settings in addition to various server configurations, however, I can't see any way to test them all.
The ironic thing is both of you have new feature requests you're waiting on.
Forum Regular
Usergroup: Customer
Joined: Aug 09, 2004
Location: Chile
Total Topics: 172
Total Comments: 462
Paul,
My aim is to be honest in order to let you realize what I see it's happening and that does not allow us to progress.
I believe that I have spend almost 80% of the time I devote to my sites in trying to understand were the bugs come from, this since I joined (take a look at the year) but now I really do not have the time nor the strenght to invest so much time on this process. I want to use the script on a professional way for sites to make some money so I need the script to work seriously, this is why I really need not bugs.
The basic difficulty are not the new features but the misfunctions. At the moment almost every upgrade carries misfunctions and some features that were working before stops working on the upgrade. This is why I do not like to upgrade and I do it only when other people has already reported the bugs...this shall be happening to other people too delaying their upgrades.
Some more ideas that you can take:
- We can have versions as 5.aa.bb in were aa means a new feature is included in the version, but bb means just a bug correction, so we can know what version we are upgrading to.
- You shall have a check list to test most of the common features after a new version is liberated (maybe this process can be automated).
- Maybe there's something that can be done on the structure of the code to isolate the current funcions from the new ones in order to reduce misfuncions when implementing new features or when upgrading.
- On the same way as you already have wsnforum implemented on philosophyforums.com you shall have a public site in were wsnlinks is implemented with all their features. This will give you a real feeling of what's happening.
Expert
Usergroup: Customer
Joined: Aug 19, 2005
Location: England
Total Topics: 391
Total Comments: 1303
In a perfect world, there'd be no new features within a series. In this world, new features implemented in the middle of a series are an absolute necessity when people pay for them, because the script wouldn't exist without that revenue. I'll try to cut back or eliminate unpaid new features in-series though.
With millions of possible combinations of settings in addition to various server configurations, however, I can't see any way to test them all.
I can fully understand that BUT it is the frequency of the upgrades. Like Daniel I am spending the majority of my time just upgrading. For instance, this month there have been 5 upgrades, December 4, November 5, October 5, September 8. When you have a number of sites running on the script it's a real pain.
Now you say that I may have to redo all my templates again when you release v.5.1 When you have a number of sites running the script and they all have highly customised templates that were only completely rewritten a year ago due to upgrading to 5, it gets rather time consuming to say the least.
The ironic thing is both of you have new feature requests you're waiting on.
I have? The only thing I can remember is concerning copying the setup, but that is not new as it was always there until a recent version when you removed it.
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7867
The basic difficulty are not the new features but the misfunctions.
The new features are what usually cause the misfunctions, of course. Feature x that worked in the 4.1 series stops working in 5.0 because of new feature y, and so on. Though sometimes a fix to one thing breaks another.
A longer time between releases would help address this problem, but I'm not sure if people want that more than they want a quick fix. I'll try out posting more of the quick fixes to the forum for manual application.
you shall have a public site in were wsnlinks is implemented with all their features.
I've got tons of them, from the customer downloads area to links.webmastersite.net.
I'll consider your versioning suggestion. That'd essentially abolish the current notion of series in favor of just major version numbers and feature releases, I guess. Problem is it could lead to having to maintain 20 different supported versions, which is unrealistic.
I have? The only thing I can remember is concerning copying the setup, but that is not new as it was always there until a recent version when you removed it.
It's new. What used to be visibly linked -- and is still there, as I explained, if you visit it manually -- isn't what you actually want.
When you have a number of sites running on the script it's a real pain.
I have around 30 WSN installations. I don't bother applying all upgrades to most of them (in fact, a few are still on the 4.1 series). Why should I? When there's something important that I want all to have, I use the multisite updater and it takes a couple minutes.
Now you say that I may have to redo all my templates again when you release v.5.1
I said I don't have a clue how different 5.1's templates will be. Do you want me to lie? I also said I intend them to be as indifferent as possible, so what do you expect?
The 4.1 -> 5.0 upgrade didn't require starting templates from scratch. It adjusted what it could and gave instructions for the rest. If you make extreme changes then that can take a long time, but you need to reconsider your changes in that case.
It took me maybe a couple of hours to upgrade simplicity and aquatic from 4.1 to 5.0.
Also, just because I release 5.1 doesn't mean you have to immediately use it. I'm sure 5.0 will be supported into 2010.
At any rate, new development is a necessity for survival. I need to complete a software directory and ratings edition this year, and to be manageable all the scripts need to share the same code base.
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7867
Due to the big problems for apache mode people and people of limited memory in the last few releases, I'm introducing betas right away. 5.0.42 will add support so that 5.0.43 will be first released as a beta. The duration of the beta period won't be fixed as described in the opening post, though.