About Litespeed versions

Discussion in 'General' started by bettinz, Dec 5, 2012.

  1. bettinz

    bettinz Member

    Hello Forum and Litespeed Tech. First of all, sorry for my English.

    I think it's time to speak about your system of release, because actually, it's not sustainable:

    We speak about a commercial product, then a lot of people pay for this software.

    Every software, usually, follow this method:
    think -> developing -> private testing -> beta public testing -> rc -> release.

    And this is the first problem. You don't follow this system: we don't know future plans, known bugs per version. We only have a little change log

    Now, assume that version x.y is available for the public (like 4.2.0, or 4.2.1):
    Every user download the new version, and test it on private server. If someone find a bug, it open a thread on this forum, and if it's approved, you update the same version.

    So, every day, I need to check if someone of the staff update the version (for example 4.2.1), and what is corrected in this new version. So, same numbers, and no change log.

    This is a "method" request: if you release version 4.2.1 to the public, and I send a bug report, please, don't update the version 4.2.1 but add a version, if you like numbers 4.2.1.1 and a change log.

    I repeat: we can't stay all the day on this forum to read if someone find a bug, or if you update the package.

    Thank you, and good work.
  2. mistwang

    mistwang LiteSpeed Staff

    Thank you for your feedback.

    We understand your points. We do not follow that route because it will really slow us down with bug fixes. We want to be stay agile/swift/efficient with bug fixes, and push bug fixes as soon as possible. We do have internal testing and beta user testing, but in real world production environment there are so many different scenarios so bugs will always come up after people use it in their busy production environment.

    We update the current release package as soon as we confirm one bug is really fixed, we try the new build on client's production environment to make sure. Leaving current release package unpatched with a private secret bug fix release package potentially causes more trouble for our customers, also may result in duplicate bug reports, which causes more overheads for our development team to deal with.

    A bug affect one customer may not affect others, as some bug fixes are for very special scenarios. You do not have to upgrade to the latest build as long as you are not experiencing any problem. If the bug is serious and generic enough that may affect many people, we will release a new bug fix version.

    We will release a new version once current release is relatively stable and we do not receive much bug reports on it.

    For a major new release, we often have a few bug fixes every day, we cannot increase the release version multiple times in a day. Even we do that, you still need to check the release/changelog page a few times a day.

    Just ask yourself, for company strictly follows what you suggested, how soon you will see a bug fix? days? weeks? months? You pay for the fast turn around of bug fixes, not wait for next new release with tons of bug fixes.

    There are a few options available for you:
    1. avoid using a major new release, usually the first few minor releases of a major release will have more bug fixes, wait till 4.2.xx released, most bug should have been ironed out by that time.
    2. try the cutting edge release, if any problem, send us bug report, back to the stable release (4.1.13 now), wait for next release.
    3. do automated daily update from command line if you want to stay cutting edge,
    we will add an option to let user download the latest build of the same release to make sure all bug fixes applied automatically.
  3. bettinz

    bettinz Member

    Thank you for the reply. I understand your point of view: maybe I'm too involved in open source projects and I can't imagine a commercial product, now it's more clear.

    Just to support my theory, you have the column build in download page. Something like 2012120301 as build, I think it's more helpful.

    Think about this: I use version 4.2.1 today. You update the package tomorrow, and the new package cause a big problem on my server, but i don't know it, because the only mode is check the date of package. If i want to download the version of today(yesterday), I can't. I mean, it's important to mantain everything clear and simple, but here we have sysadmins and not (i think) final users. So, ok the easisest way, but think to sysadmins and server manager.

    Thank you.

    I think it's an important step ;)

Share This Page