DirectAdmin 1.684

fln

Administrator
Staff member
Joined
Aug 30, 2021
Messages
1,216
We are happy to announce the release of DirectAdmin 1.684.

A full release change log is here:

DirectAdmin 1.684


The update should be automatically available for all installations subscribed to the current release channel.

We appreciate all the feedback on forums and issues reported in the ticketing system.

Thanks!
 
Can I go on record and say that I'm not a fan of this new rapid release schedule?
I have to say i'd agree here also, but it's also a double edged sword. I totally understand rolling out hotfixes and security patches are high priority and new features are often nice to have, especially if they save you time and sometimes software providers take an age to release. So you're damned if you do and damned if you don't I guess 🤷‍♂️
 
I have to say i'd agree here also, but it's also a double edged sword. I totally understand rolling out hotfixes and security patches are high priority and new features are often nice to have, especially if they save you time and sometimes software providers take an age to release. So you're damned if you do and damned if you don't I guess 🤷‍♂️
What new features have been added since 1.680? It looks like most of the changes in recent updates are fixes or updates. Could 1.681, 1.682, 1.683, and 1.684 all just be "hotfix" releases for 1.680? I would probably concede that 1.681 introduced the web based installer, so maybe 1.682, 1.683, and 1.684 being hotfix releases for 1.681.

I liked it better when DirectAdmin versions were 2 to 3 weeks or maybe even 4 weeks in-between. I'm not including the various "hotfix" releases that come about after each new version released.

I'm still on 1.680. I generally prefer waiting about 2 weeks+ before updating because I don't want to have to go through all of the "hotfix" releases. There's usually a thread on these forums after each release that gets to be 4 to 5 pages long of "issues" (to DirectAdmin's credit here I'm not sure if these are really issues or just end-users not understanding what something is) I like to let that play out first. Lately the release threads haven't gotten that long because the release schedule has been accelerated.

DirectAdmin 1.680 was released on July 17th.
DirectAdmin 1.681 was released on August 11 - 25 days after 1.680
DirectAdmin 1.682 was released on August 25 - 14 days after 1.681
DirectAdmin 1.683 was released on September 2 - 8 days after 1.682
DirectAdmin 1.684 was released on September 9 - 7 days after 1.683

I'll admit I dragged my feet on upgrading to 1.681. It was on my todo task list for the previous week, but I didn't get to it. The 11th was a Monday and I was getting read to deploy the 1.681 update that week, but 1.682 dropped so I postponed that. 1.682 lived for 14 days, that's on the cusp of what I like to allow for. I hadn't exactly prepped for the update to 1.682 but it was in the scheduling stage. But then 1.683 dropped, so that postponed 1.682. I never even considered updating to 1.683 and now I'm looking at 1.684. At this point I wouldn't be shocked if we're at 1.685 by the weekend.

Now, I could drop back to stable instead of current. But the delay (or lack thereof) is still the same. When a new current drops, the previous current falls to stable. So you're still looking at 14, 8, and 7 days in-between those releases.

To be fair, I'm sure not everyone follows my preferred method of testing each new release and letting "issues" play out to see how they may affect me in a production environment. I'm sure not everyone has the level of customization I have in my production servers and if you're just running vanilla DirectAdmin then update to update probably isn't a huge issue. For that you probably want more rapid releases because it minimizes the amount of time any "issue" stays there. But I'm just not one of those people. Majority rules, so I'm not necessarily complaining. But I am voicing an opinion in case anyone that handles DirectAdmin releases wants input on these rapid release schedules.
 
Thanks for the feedback @sparek. Our goal for the time being is to try and keep-up and make a new release every week. Before it used to be 2 to 3 weeks between releases.

Faster release cycles allows us to bring improvements that would not normally be considered hot-fixes faster to the users. For example new versions of the 3rd party software. Also fixes for some things that are not newly introduced in the latest version (for example File Manager showing last modify time rather than file create time). Another reason for faster release cycle is to allow translation updates to propagate faster. Sometimes for minor translation fixes users need to wait a full release cycle.

The recent release pace was increased to help us deliver the CSF update faster. If CSF is not updated to the latest version (where auto updates are disabled) it keeps sending daily error messages about failures checking for new version.

Our goal is just to have a consistent release-cycle at fixed interval of time instead of waiting until we accumulate a specific amount of new features.

By the way a new build is pushed out with a small fix for the Evolution plugins page. When login-as feature is used plugin page used to not account for the top bar size and would hide a 50 pixels of plugin page bottom part. This would not normally be considered a normal fix (not a hot-fix) because plugins page was introduced in DA 1.681. But since it was spotted and fixed the same day we made a release we decided to just pull it into DA 1.684 to push it out faster.
 
Last edited:
Under 3 hours between updates. Now that IS efficient service! 😁 🤣🤣🤣
1757443706779.png
 
Thanks for the feedback @sparek. Our goal for the time being is to try and keep-up and make a new release every week. Before it used to be 2 to 3 weeks between releases.
Meh!

I'll withhold the rest of my opinions on this. But I will add this... and maybe other administrators of larger number of production servers will chime in (maybe they chime in stating they don't have a problem with this).

Rapid release schedules, frequent updates, or just updates in general are one thing when you have a server system of one server. Or two, or three... I don't really know where the cut off starts. But take 10 servers... it's probably a little different. 20 servers... even more different. 50 servers...

The more users you have the more opportunities you have for uncovering issues caused by an update. The more servers you have with these opportunities you more likely you are to reach a collision. Say you have 50 servers. You update 12 of them, everything is going fine. Suddenly a user on one of those 12 servers finds a bug in the update. Do you continue updating the other 38 servers? Or do you pause? You know there's an issue... do you want to bring that issue about to the other 38 servers? If you pause and wait for another release, then you go through updating the servers again. This time you get to 20 servers before someone finds a bug. Now you've got 30 servers that are two versions behind already. And it just starts to spiral out of control.

Would a real LTS release be a solution here? I'm not talking about just pushing the previous current to stable. This would involve differentiating between "fixes" and "features". So that "fixes" are pushed back to the LTS release but new "features" can continue to be added and the versions can keep incrementing. But those of us that just want a stable set of working "features" without the headache of working with new "features" all the time can continue to use an LTS version that only gets "fixes" from newer versions.

A just think some input from administrators that have a lot of servers (no clue what defines "a lot") regarding their opinions of this rapid release schedule, could be valuable.

Also administrators that have extensive use of customizations - whether that be CustomBuild compilation or configuration customizations or the extensive use of event hooks - what are their opinions of this rapid release schedule?
 
Back
Top