24

As with many things in computing, it depends. If the patches are a response to customer requests for new features or improvements, then your company will be viewed as responsive. If, on the other hand, your patches are a response to bug reports, then your company will be viewed as incompetent. Testing software on your customers is by far the most ...


23

"File prevalence/reputation is low" means Avast uses a reputation system based on the usage of the program. Only if your program has been installed and 'marked as benevolent' by enough users will it develop a good reputation and will this suggestion go away. Avast calls this the FileRep cloud feature and says "All new unknown files are potentially dangerous. ...


18

You can think about updating Bootstrap the same way you would think about any other dependency. Does it introduce breaking changes? What benefits do you get from upgrading? Do the benefits outweigh the risk or time investment? In the context of a CSS (and potentially JS, if you use the helper scripts) dependency, these questions can be thought of this way: ...


15

There is more to testing than unit testing. You need to test the new features and bug fixes you created manually in a testing environment that mirrors a real-world installation as best as possible. Having one of the other developers 'review' changes is not an appropriate level of testing for two reasons. First, that implies they'll give it a quick look ...


11

Yes and no, both mechanisms work. The easiest way to patch a product is by replacing a component (eg a dll) with a new version of it. This usually requires the program to be stopped so its useful for a game or other program that is run occasionally but not so good for OS components. So various techniques have been developed to directly patch a running ...


10

I feel like releasing several patches in close proximity reflects poorly on the company. It always makes me feel like they didn't test throughly enough up front, that the developers are incompetent, or the management has no idea what they are doing. That being said, the other side of the token is that releasing several patches close to one another shows ...


9

Just as you can create a patch for a text (source) file, you can create a patch for a binary file as well. You are effectively just noting what changed between two files (that's called delta encoding). For example, if the app contains many resources, then those don't usually change for smaller updates, and only the executable code itself needs to be ...


8

The short answer is that the new version could introduce new bugs, as Robert Harvey mentioned in the comments. To be honest, I think you are approaching this the wrong way. In my experience, the better approach is to default to sticking with the version you have. Presumably, your team has already tested the version you use and how it integrates with your ...


7

Orace has adopted a pretty weird numbering scheme: Since the initial release of JDK 5.0, Java update releases have either been Limited Update releases that include new functionality and non-security fixes or Critical Patch Updates (CPUs) that only include fixes for security vulnerabilities. We will continue releasing Limited Update and CPU Java releases, ...


7

More and more companies follow in Chrome's footsteps and have more and more frequent customer releases. The pre-requisite for implementing short release cycles is a painless upgrade - in chrome, for example, the upgrade is done without user intervention at all on application start-up, and if the user keeps his application always on, he receives a minor flag ...


6

Git is not a deployment mechanism. It is a distributed source control tool. You are creatively using the “distributed” part to manage and deploy your artefacts, but that is not playing to Git's strength. Instead, storage of binary assets is a weakness of Git, because this results in a very large history, and no meaningful diffs are possible. I have worked ...


5

The answer is more tests. Unfortunately, that isn't the answer you want to hear, but it really is the only solution. As you noted, the last roll-out went disastrously, which is most detrimental to customer satisfaction. It would be better to build a solid product with fewer new features than to build a whole bunch of buggy features on a buggy base. "This is ...


5

The main reason it is not wise to bundle your own copy of OpenSSL (or other commonly used libraries) is that your project will not be the only thing your end users install that uses those libraries. If you depend on the installed system version of OpenSSL on the host where you run, your users need only update that copy of OpenSSL when a new security issue ...


4

Deprecated or obsolete products or frameworks are usually best categorized (and "sold") as Technical Debt. If the new version offers fantastic improvements or benefits, then your job is easier. But even if it doesn't, staying on an older version incurs several risks: Lack of developer support. This is never a problem until it's a problem - get it? Lack of ...


4

You probably don't want to do an update that frequently. With a daily update, you run the risk of hosing ALL your users if there's a problem in your update (I'm looking at you, Microsoft). And then you get to deal with the resulting complaints and support issues. If you make the frequency of the checks lower, if a problem does occur, it will affect a ...


4

To answer, let me first turn the question around on the need to upgrade. If you never upgrade, over time you are stuck on an outdated version and will find bugs in your system that results from bugs in the library that have been fixed in later versions. Assuming that you are continuing to develop your system, and the relevant library is of any size of ...


4

It depends if you have persistent state like a database or runtime configuration, and if you care about retaining that state. If you do, it's best to do the upgrade in steps, because this is how the developers test and support upgrades. Occasionally, developers will also support larger upgrades. Ubuntu's LTS versions are a good example. If you don't have ...


4

Presumably these companies have "locked down" their user desktops for [what they consider to be] Good Reasons. By implementing a mechanism that circumvents their Policy, you are opening up a whole can of legal worms. Talk to these IT departments about how they manage application deployment and work with them. Don't try to "work around" them. You are a ...


4

The software development lifecycle is more than development – it also involves maintenance and decommissioning or replacement of the software. So asking “what about in X years” is generally a sensible question. The big reason why you want to use a supported Python versions is security, especially for network-connected software. Using a recent Python version ...


3

That depends on the nature of the security holes and that of your application. The most popular and major ones that have been fixed are related to applets. This is to say that there's some hole in the Java stack (JVM, native libraries, Java libraries, etc.) that allows an applet to access e.g. files on disk, to run a process, the kind of things that applets ...


3

Consider two points: Privacy. If the application sends information to you every time I'm launching it, it says too much about me. If I start your application very often, you can gather some statistics which I would consider too intrusive of my personal life. Over a few months or years, you'll know statistically when do I use my computer from Monday to ...


3

You could do something like @Uwe describes, but have the file contain an encrypted string. The string will contain, as part of its value, the install date (or expiration date) and ... other stuff. What the other stuff is doesn't really matter unless you want other validations. We do something similar but store the value in our app's database. Our ...


3

Is there a specific problem you're having with the current model? If the application is installed on systems that normally have internet access, you could do this on a server to avoid the situation where someone plays with their system clock and runs the application longer than 6 months. When the application is installed, it registers itself with your ...


3

Focus on just doing a good job with your tasks. Work on being a better developer. Solve your own imperfections before you worry about that of the company. Create a reputation in the company as a person who can be trusted with an assignment. Test your own work. Write unit tests for your changes. Demonstrate the behavior of a professional developer that ...


3

Upgrading software which is packaged is complex and is best done with a software installation tool. This is a classic case of build vs. buy. You couldn't build something yourself that does the job of InstallShield, for example. Upgrading software which has been customized is a very tricky proposition. In general this is next to impossible to do in an ...


3

RFC 7231, Section 4.3.1: A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. So in short, sending a payload is indeed incorrect. As far as REST goes, use POST if you're creating an item, and PATCH for partial updates or PUT for full ...


3

According to the documentation, anonymous information about the user's system is sent with an update request. I'd say that technically your colleagues are correct. This info doesn't appear to be used to affect the response to the request, so it doesn't really belong there. A better way to send that info would probably be to POST to a separate resource, ...


3

When the executable is changed, it's often easier to replace the entire executable, rather than modify it. This makes it possible to patch the executable no matter which version it's at (unlike binary difference patchers). The vast majority of modern games do it like this. In modern games, the size of the executable pales in comparison to the resource files,...


3

AFAIK what you call "ECO" in electrical engineering is called a "change request" in software development. Many development teams use issue or bug tracking systems to manage their change requests in form of "tickets", and I am pretty sure a certain percentage of those teams add the issue ID, or bug ID, or ticket number, to the commit messages when committing ...


Only top voted, non community-wiki answers of a minimum length are eligible