Tag Info

Hot answers tagged

50

In my opinion, it's a good practice, assuming your users have read access to your bug database. There are lots of times when people are waiting on a certain bug to be fixed in order to decide when to upgrade. I think what's frowned upon is only citing the bug id and nothing else. You should always also supply a description that is understandable without ...


14

It is, as said in the quoted comment... unfriendly. Unfriendly with yourself Imagine the following scenario. You are viewing the logs in source control. You are wondering what a commit changed. Instead of explaining it in plain English, it tells you: Solved #1307 You run the bug tracking system, hoping to have something helpful. Bug #1307 is reported ...


12

If you can't use a later version that doesn't have the problem you're encountering, the only options you have are to either live with the problem and find a workaround fork the library and fix it in your private version (which is what you'd effectively be doing) throw in the towel and tell your managers that the problem is insurmountable (which would be a ...


12

As far as I'm concerned, if you find a bug or have an enhancement request, are not a contributor to the project, and have submitted a defect report through the appropriate channels, you are done. In terms of giving back to the community, anyone who is using an open source project and finds a defect should report it. Attempting to find a solution, design it, ...


7

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 ...


6

What you are about to do is a bad idea in the more common case where you bundle third-party software and intend to track their releases. Usually people do that because they want a feature in the third-party component that the maintainers aren't willing to implement, or to implement in the way you need. You, however, explicitly said that you will not upgrade ...


5

The bsdiff utility should come with OSX. If that can't work for you, there are other binary diff tools. However, with the advent of high bandwidth connections, the practice of distributing binary patches is becoming much less common. You can just as easily distribute a complete updated version of your program if need be.. FURTHER: A [good] module ...


5

If you are using the original code base for which the patch was built in ANY way, you must use the GPL license. If your patch is fully independent (which patch that is fully independent is not really a "patch") and can stand on its own two feet, then use whatever licensing you want. This may help clarify http://www.sitepoint.com/public-license-explained/


4

Where I work we use the following terminology: Snapshot Developers share these around with each other (example-0.0.1-SNAPSHOT) and are built over and over while developers get to grips with the various user stories and tasks. These never go beyond the development servers. To get beyond 0.0.1-SNAPSHOT you normally have to go through a release, but major ...


4

Proceed as far as you're willing to put up with it. It'd be nice to fix up your patch and share it with the world in the main trunk, but if the maintainer doesn't want it, shrug. You can post somewhere your problem, and the patch to deal with it, so that others in the same boat can search for a solution. And you're not without problem. Your patch won't be ...


3

There's really not anything wrong with doing that as long as everyone can stomach the costs, benefits and risks. ...the fix seems simple enough ... to patch the code myself When you have a job to do, perfect (having a third-party library that's exactly what you want) is the enemy of good enough (patching it yourself), and sometimes you have to do ...


3

Edited to reflect comments: For development you want Nuget... You can easily run your own nuget repository (can be a folder, TeamCity has one built in, etc). Build the libraries with a self contained suites of tests, use semantic versioning, update and deploy at will - semver and the nuget systems will give you enough control to avoid updates you want to ...


3

The whole program gets updated. In essence the operation could go as follows: Request updates Download updated files Replace current files with the new downloaded files Details how to manage this may vary, because for example it might not be possible to delete an executable file of a running process, so some form of a workaround is needed(run the updater ...


3

There is one tenet that makes open source culture easier to understand: the person who does the work decides what to work on. This is one of its appeals compared to developers' day jobs. Your #1 priority might be #50 on their backlog. If you don't fix your pull request, eventually it will probably trickle up to the top and they will take care of it. ...


3

Release - user pays Update, Patch, Bug Fix - user paid for service contract (Could be included with Release) Upgrade - User pays again


2

There's nothing wrong with citing issue numbers in patch notes, provided users can read the issue which is being cited. If your bug database allows anyone to read, citing the bug number can be very useful indeed. (One better, if your patch notes are in a format that allows links, make those issue IDs be links to the issue in question.) This doesn't mean that ...


2

There's nothing particularly standard about this. Some common uses: Release: a new version with major changes from the old version. Typically, the user pays for this as a new product, or as an upgrade from a previous release. Update: a new version that probably has significant changes to functionality, or many minor ones. Typically, this is either ...


2

I personally enjoy a 4-numbered version, however there's no standard for versioning. The last digit I auto-increment everytime I deploy, so I'm sure I always have a new version without having to worry too much about the significance. Usually I'll increment the third number only when I add a noticeable feature or behavior of the program (as opposed to ...


2

It obviously depends who the people that will read the patch notes are, and the target users of the software. But in most of cases, the vast majority of your users simply don't care about what the bug ID is. They don't care why it was broken, what the fix is, or anything else -- they only want to know what changed with a very succinct textual description ...


2

AFAIK, the open source way is that the responsability of fixing bugs is left to the one who care enough about the bug to handle the burden to ensure it is fixed. Depending on the circumstances, I've done everything from simply ignoring an issue to battle up (providing patches and arguing so that they are accepted) to ensure it was fixed. Everything is ...


2

What you want to do seems reasonable enough, but it sounds like there are (sound?) process reasons for opposing it. I won't compare the proposed solutions, but perhaps there's a way you could have your cake and eat it too: If the open source project in question allows it, contribute your back-ported bugfix to their repository. That is, if you're using ...


1

For production you want to use Windows installer - MSI - files. Once its installed correctly, you can use patch installation file to update (msp files). The Windows Installer site has a whole heap of information on patching and upgrading. I'd use Wix to create the installer files in the first place.


1

The most straightforward way is to create a local branch in your git repository and then merge the remote changes into your branch as they arrive. If you think of the software as "my modified version of the upstream project", then this ought to make sense. However, another option is to use quilt (summary; offical page). It is a way to manage sets of patches ...


1

To an open source developer, there are two types of problems: (a) problems without a patch (b) problems caused by a patch I think most open source package maintainers/developers LOVE the idea of helping to get a non-core-contributor up to speed with their patches. Their primary goal, however, is minimizing the number of type-b problems. That's why the ...


1

A bug ID is mandatory for a point of reference. The reasons: Prevent ambiguity: Two or more bugs might have similar descriptions. So one would need some anchor to distinguish between them. Convenience: When discussing a bug, either with a customer or internally, the bug ID is often used for as a short form. If the ID will be omitted from the patch notes, ...



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