The biggest issue here, I think, is a question of priorities. I think that a developer section of the Enterprise site with a detailed changelog would be a good thing, but we don’t think it’s the most important thing right now. For Enterprise, we will continue to focus on fixing bugs, adding stable performance increases, trying to increase the compatibility of the software, and improving our documentation. (It’s worth noting that there are other examples of proprietary software that give abbreviated release notes — off the top of my head I can think of Plesk and IIS.)

For OpenLiteSpeed, on the other hand, you are right, we will need to implement a way that people can see exactly what has been changed. Some open source projects do not include a detailed release log, but rather easy ways to diff the source codes. OpenLiteSpeed is still in its infancy and we are not sure exactly what method we will be using to make changes more clear. We are concentrating first on getting the code more stable and making the software easier to use. We will also be differentiating between OpenLiteSpeed 2.x (which will include more experimental advances), and OpenLiteSpeed 1.x (which will be the stable version, at first). For Enterprise, however, stability is always paramount.

Michael

As you can see, they release a lot of updates with new versions, like you (it’s normal with every new version), but they keep updated what change.

So, this is how I work and I release my software:
EDGE VERSION: 1.1, 1.3,1.5…
Stable version: 1.2,1.4..

In edge branch, i release sometimes hourly updates, but I keep this tracked in my changelog.
So I have: 1.1.3, 1.1.7, etc
When it’s stable, it will be, 1.2 with only rare bug fix for stable user.

This is what I say about software release cycle some time ago (search in the forum with my nickname), and this is the change you need if you want an opensource community around LiteSpeed (the only release of OpenLitespeed is not enough, you need to change your software release cycle, in my opinion)

I think a developer’s section is an interesting idea, but I don’t think we’re going to be pursuing it at the moment. We do have a small but healthy community of of bleeding egde-ers who download new versions as soon as they come out and catch a good number of bugs. Of course we’d like to see that community expand, but, for the moment, we’re satisfied with this community’s (and our internal testing’s) ability to find important bugs and we feel there are other areas we need to pay attention to more. I, especially, will be looking to see if there are things we should be including in our release logs that aren’t there — and if anyone has an example of a bug fix that they feel should have been in the log but wasn’t, please email info(at)litespeedtech(dot)com — but it often seems that the next level of detail would involve very elaborate explanations of situation-specific errors. This, I believe, would cross the line of what is useful. But, again, it’s a fine line and if anyone has any examples that would help us find that line, I’d be very interested.

I think it’s better that we focus on things like the autoupdate feature you mentioned (which we absolutely want to implement), updating and expanding our documentation, and improving our communication with the community (through places like this blog).

Michael

About the autoupdate: I mean, add the ability to update every day automatically, or when the package is updated; if i want to try 4.2.3, and it’s not full stable, maybe I want an automatic update for the 4.2.3 released tomorrow

So, you want a more detailed release log, right? We might be able to do that, but there’s a limit to the amount of data we can put in the release log. At a certain point it’s just going to become overloaded (both for us writing it and for you trying to figure out which bugs are important). We try to put bugs into the release log that we think have the possibility to affect a number of people (software compatibility issues, rewrite problems, etc…) and we’re trying to get more specific. Are there other kinds of bugs you would like to see in the release log?

As for the autoupdate, it will be enabled as soon as we’re sure of the stability of the build. It’s been released now for users who want to try the newest build. In about a week, when we’re more sure it’s stable, we’ll push it to autoupdate.

Cheers,

Michael

Remember: we can help you with bug fixing if we are quiet about updates. If I know what you fix, and what areas are critic, we can help you to make Litespeed better. And if i know what you fix today or tomorrow, we can say: yes, it’s fixed. You have a great community, and the better webserver. Thanks for the great work

save contents in product-boostv1.xml file