DirectAdmin v1.63.5 has been released

DirectAdmin Sales said:
Maybe there is no problem here
Click to expand...
Yes there is, or rather a misunderstanding I think. Stable should point to older software at a later release time, indeed as you explained.

However I think I understand where the misundertanding is coming from.

It depends on how dangerous the thing is what is fixed. A lot of software (like also Windows, Xenforo, IPB, and loads of other things) contain security fixes when there is an upgrade present. Mostly those are not very important security fixes.
Important security fixes (like polkit) c.q. security fixes which fix some important leak which could danger the system, are brought out as a patch on all versions, so stable, beta, whatever.

So I think it's important to know which kind of security fix is made. Because my guess is some people (including myself) are now wondering as to what kind of fix this is.

Nickske00 said:
When PHP fixes a security bug and the release takes place in the monthly cycle, you still have to wait
Click to expand...
That is exactly what I mean.

There is no need to delete "stable" as PHP which gets updates later can also be stable. But it might be wise to name the security fix minor or something or as long as it's clear to everybody that important fixes are done immediately over all branches including stable, then it should be fine.
 
First if its a CVE, Exploit, Security fix it is important on some level. That level is usually defined by the security auditing company. Not the company or group writing the code. Because if the company had know previous to the audit they would or should have fixed the issue.

The other thing is the code I believe we are speaking of is Closed Source and Proprietary. It is owned and maintained in secret by DA. PHP, Exim and others are not. This being the case DA is and should be held to a higher standard. They have a duty to the license holder. PHP and other open source does not. "the GPL clearly explains that there is no warranty for this free software" Although DAs license is not much better "Although the Software is designed to operate in accordance with the written documentation provided by us, we offer no express or implied warranties or guarantees as to the fitness or functioning of the Software."

In some cases we think Stable means older in time. I the case of PHP its the best we can do. Although some opensource projects have more people and more testing than one might summarize DA does. This because of the Close Source hence they have to do all the testing and validating the stablity of their software. In reality Time is only one element of being "stable". There are many others. The theme I keep seeing is their definition of "Stable" is just code made several months ago. Which is not all stable means.
 
bdacus01 said:
Which is not all stable means.
Click to expand...
No but it is a fact in most cases as it's a result of stable. Stable and tested is mostly older code. But indeed stable has another meaning but using older and stable is shorter to write I think.
 
sparek said:
Perhaps you need to change the name of "stable" to "previous" if it's only purpose is to be an agent of downgrade.
Click to expand...
That suggestion makes a lot of sense to me and seems a more correct name than stable to me.
I actually considered moving to stable and will certainly not do so after reading this thread.
 
I do think DA should rethink their approach, because it can be confusing. A stable version generally refers to software with a certain set of features that have been well tested and relatively bug free. When new features are introduced, that version of software may not be stable for weeks or months. The thing that DA does, which I think is a bit odd, is they keep the same version number but if they find a bug, they change the build number. This just happened with version 1.63.5 - a new build was just pushed out. To me, it makes more sense to apply the security fix to the stable version (unless that version does not have a security problem) and update the build number (using DA's current approach).

In any event, it does not look like 1.63.5 fixes all the security issued found by Rack911
 
DirectAdmin 1.63.5 build 31a591d7c77e2681fa224c4ec9ad341e3b127be1 to 1.63.5 build 1d0fc38326e248a017776fbd3be4074d2dfacb1e update is available.

Seriouosly?
Changing sum without changing number of version?
And what should I do? No changelog, no details.... looks suspicious
 
hi everyone, today we have re-packed the 1.63.5 release changing the build ID to 1d0fc38326e248a017776fbd3be4074d2dfacb1e. The only change in this build is the system message that is send out to server admins after upgrade. All the code is identical to previous 1.63.5 build.

With this new DA build we are testing out the release mechanism before releasing 1.63.6 which is already in beta.

The way our new release system works is that we issue no change-log or release notes for new build of the same release with a minor fix. We have already used this release mechanism a couple of times, example https://forum.directadmin.com/threads/directadmin-v1-63-4-has-been-released.65327/#post-340896.

Also we repacked 1.63.5 for CentOS6 and RHEL to avoid showing update available message when the system was already up to date.

As @k1l0b1t mentioned a different version naming scheme would be better, but we are still locked to x.y.z release name in multiple paces in our infrastructure. Once we make some changes we could move to a more accurate version names (for example having sequential build ID).

Hope this clarifies the situation. Feel free to upgrade to 1d0fc38326e248a017776fbd3be4074d2dfacb1e at any time without worries or wait until auto-update feature will be triggered.
 
Right now have a system, where build numbers (commit hashes) are tightly coupled with our source code repository. Any change to our system updates the build ID. Even changes that does not touch the source code of DA, for example updating CI/CD pipeline, or change to some auxiliary shell script that is not even shipped with DA.

I think this is great from the visibility perspective. You can be sure that we can not make any changes without changing build ID, even if the change is not in the source code but in the instructions on how we build software. It is also helpful when comparing DA versions installed on different machines.

But this is a double edged sword for us. Old release system would allow us to just upload new binaries (new build) under same version and no one would notice the difference. But now we can not do it :).

Our policy is that we document changes in change-log for and bump DA version for each release. But if we want to re-pack existing release we keep version the same because we know build ID will reveal the re-pack for you anyway. I am deliberately using a word re-pack rather than update here because it means the change is minimal and 100% compatible with previous build.

So far every time we do a re-pack I can see new posts about it in the forums almost immediately ?. I am happy this change in the way we build DA improves visibility. The only downside is that changes are usually not even worth mentioning. Anyway I am ready to give you details about repacks.
 
Auto-update feature only updates DA and all related files, most of the /usr/local/directadmin static contents. It does not update custombuild, or the other services.
 
@Freddy, yes new place for release notes is docs.directadmin.com change-log section. We are in the process of migrating old change-log notes to the new system. Main link on the directadmin.com (top right corner showing latest version) already points to the new location. But it is worth mentioning in the versions.php as well (y).
 
You must log in or register to reply here.
Back
Top