Search Results

Search found 525 results on 21 pages for 'versioning'.

Page 4/21 | < Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

• Best practice for marking a bug as resolved in Bugzilla ?

  - by Vincent B.

  I am wondering what is the best way to handle the situation of marking a bug as resolved and providing a version of component/product in which this fix can be found. Context For a project I am working on, we are using Bugzilla for issue tracking, and we have the following: A product "A" with a version number like vA.B.C.D, This product "A" have the following components: Component "C1" with a version number like vA.B.C.D, Component "C2" with a version number like vA.B.C.D, Component "C3" with a version number like vA.B.C.D. Internally we keep track of which component versions have been used to generate the product A version vA.B.C.D. Example: Product "A" version v1.0.0.0 has been produced from component "C1" v1.0.0.3, component "C2" v1.3.0.0 and component "C3" v2.1.3.5. And Product "A" version v1.0.1.0 has been produced from component "C1" v1.0.0.4, component "C2" v1.3.0.0 and component "C3" v2.1.3.5. Each component is a SVN repository. The person in charge of generating the product "A" have only access to the different components tags folder in SVN, and not the trunk of each component repository. Problem Now the problem is the following, when a bug is found in the product "A", and that the bug is related to Component "C1", the version of product "A" is chosen (e.g. v1.0.0.0), and this version allow the developer to know which version of component "C1" has the bug (here it will be v1.0.0.3). A bug report is created. Now let's say that the developer responsible for component "C1" corrects the bug, then when the bug seems to be fixed and after some test and validation, the developer generates a new tag for component "C1", with the version v1.0.0.4. At this time, the developer of component "C1" needs to update the bug report, but what is the best to do: Mark the bug as resolved/fixed and add a comment saying "This bug has been fixed in the tags v1.0.0.4 of C1 component" ? Keep the bug as assigned, add a comment saying "This bug has been fixed in the tags v1.0.0.4 of C1 component, update this bug status to resolved for the next version of the product that will be generated with the newest version (v1.0.0.4 of C1)" ? Another possible way to deal with this problem. Right now the problem is that when a product component CX is fixed, it is not sure in which future version of the product A it will be included, so it is for me not possible to say in which version of the product it will be solved, but it is possible to say in which version of the Component CX it has been solved. So when do we need to mark a bug as solved, when the product A version include the fixed version of CX, or only when CX component has been fixed ? Thanks for your personal feedback and ideas about this !

  Read the article

• How to manage and improve web application with 50 customers?

  - by Muhammet Göktürk Ayan

  First of all, sorry for my English. We've developed a Web Application using ASP.NET and Sql Server. We've started selling it and of course are still continually improving and developing it. The question is, how do we go about updating each client's version of the site? We have, maybe, 50 customers. 50 different folders and 50 different db's sounds like a bad idea. Is there any known method for solving this kind of scenario? For Explain: We are developing a Crm, for 50 companies. They will have 10 users maybe. It makes 500 users and their customers and products.

  Read the article

• Are there any drawbacks to the Major.Minor.YMDD.Build version strategy?

  - by Chu

  I'm trying to come up with a good version strategy to fit our specific needs. We've proposed settling on this and I wanted to ask the question to see if anyone's experience would suggest avoiding this or altering it in any way. Here's our proposal: Versions are released in this format: MAJOR.MINOR.YMDD.BN. Here it is broken out: MAJOR & MINOR are typical; we'll increase MINOR when we feel code and new feature sets warrants it; once every few months most likely. MAJOR will increase ~yearly. YMDD: Y will be the last digit of the current year, so "1" for 2011, "2" for 2012, etc. A non-padded month will be used to keep the number smaller (9 instead of 09 for example). DD of course is the day, padded with a zero for days under 10. BN: BN is the build number and increases by one anytime we make a change to a branch of the code represented by the build, for example: If were to make a build today, our release would be version 5.0.1707.1. I release to QA today and 3 days from now QA finds that a change broke the save functionality on a page. Instead of me changing our current development code, I'd go back to the code that I used to create version 5.0.1707.1, make the fix there, then increase the BN portion of the version and would then re-release 5.0.1707.2 back to QA. In short, anytime a change is made to a branched version that isn't the active dev branch, we'd use the original version number and increase only the BN portion (even if the change happened 3 days, 3 weeks or 3 months from the initial release of that version). Anytime we make a new release from our Active dev branch, we'd come up with a new version based on the M/D of the release using the outlined strategy. We do this once every 2-3 weeks. Are there holes or pitfalls with this? If so, what are they? Thanks EDIT To clarify one point that I didn't get out very well - Oct/Nov/Dec will be two digits, it's only the year that won't be. So 9 for Sept, 10 for Oct, 11 for Nov, etc.

  Read the article

• How can I add the version of a file to the file name with Tortoise-SVN?

  - by Eric Belair

  I would like to start giving unique names to "cache-able" files - i.e. *.css and *.js - in order to prevent caching, without requiring changes to the web-server settings (as is currently done in IIS). For instance, let's I have a JavaScript file called global.js. Going forward I would like it to have the name global.123.js when revision 123 is checked in. This would also require the following: The previous version of the file - perhaps it was global.115.js - is removed when the file is deployed. All references to the file are updated with the new file name How do I go about doing this? What concerns do I need to consider?

  Read the article

• When should I increment version number?

  - by ahmed

  I didn't learn programming at school and I do not work as a (professional) developer, hence a lot of basics are not quite clear to me. This question tries to clarify one of them. Now let's suppose that I have issues #1, #2 and #3 in my Issues Tracker that are set to be corrected/enhanced for version 1.0.0 and that the last (stable) version is 0.9.0. When should I increment to version 1.0.0 ? When a) just one of the listed above issues is closed or b) when all the issues related to version 1.0 are closed ? Which one is the right way to do it ? And by the right way, I mean what is currently used in the industry. Thanks.

  Read the article

• What is your strategy for converting RC builds into retail?

  - by Matthew PK

  We're trying to implement a strategy for how we transition our builds from RC to released retail code. When we label a build as a release candidate, we send it to QA for regression. If they approve it, that RC then becomes our released retail code. I liked the idea of "obvious" labeling of versions so that a user knows whether they have a beta or an RC or retail code... where you would have some obvious watermark in non-retail code (think Windows 7 where the RC or non-genuine builds watermark in the bottom right). ... but it seemed strange to us to manipulate the project (to remove the watermark) once it passed regression. If QA certified version a.b.c.d then our retail code should be that same version, not a.b.c.d+1 what strategies have you employed to clearly label non-release software versions without incrementing your build to disable the watermarks in your retail code? One idea I've considered is writing your build to look for a signed file in the installer archive... non-release code wouldn't include this file and so the app would know to display a watermark. But even this seems like QA is then working with non-release code. Ideas?

  Read the article

• Best practices for upgrading user data when updating versions of software

  - by Javy

  In my code I check the current version of the software on launch and compare it to the version stored in the user's data file(s). If the version is newer, then I call different methods to update the old data to the newer data version, if necessary. I usually have to make a new method to convert the data with each update that changes user data in some way, and cannot remove the old ones in case there was someone who missed an update. So the app must be able to go through each method call and update their data until they get their data current. With larger data sets, this could be a problem. In addition, I recently had a brief discussion with another StackOverflow user this and he indicated he always appended a date stamp to the filename to manage data versions, although his reasoning as to why this was better than storing the version data in the file itself was unclear. Since I've rarely seen management of user data versions in books I've read, I'm curious what are the best practices for naming user data files and procedures for updating older data to newer versions.

  Read the article

• Supporting and testing multiple versions of a software library in a Maven project

  - by Duncan Jones

  My company has several versions of its software in use by our customers at any one time. My job is to write bespoke Java software for the customers based on the version of software they happen to be running. I've created a Java library that performs many of the tasks I regularly require in a normal project. This is a Maven project that I deploy to our local Artifactory and pull down into other Maven projects when required. I can't decide the best way to support the range of software versions used by our customers. Typically, we have about three versions in use at any one time. They are normally backwards compatible with one another, but that cannot be guaranteed. I have considered the following options for managing this issue: Separate editions for each library version I make a separate release of my library for each version of my company software. Using some Maven cunningness I could automatically produce a tested version linked to each of the then-current company software versions. This is feasible, but not without its technical challenges. The advantage is that this would be fairly automatic and my unit tests have definitely executed against the correct software version. However, I would have to keep updating the versions supported and may end up maintaining a large collection of libraries. One supported version, but others tested I support the oldest software version and make a release against that. I then perform tests with the newer software versions to ensure it still works. I could try and make this testing automatic by having some non-deployed Maven projects that import the software library, the associated test JAR and override the company software version used. If those projects build, then the library is compatible. I could ensure these meta-projects are included in our CI server builds. I welcome comments on which approach is better or a suggestion for a different approach entirely. I'm leaning towards the second option.

  Read the article

• What makes an effective UI for displaying versioning of structured hierarchical data

  - by Fadrian Sudaman

  Traditional version control system are displaying versioning information by grouping Projects-Folders-Files with Tree view on the left and details view on the right, then you will click on each item to look at revision history for that configuration history. Assuming that I have all the historical versioning information available for a project from Object-oriented model perspective (e.g. classes - methods - parameters and etc), what do you think will be the most effective way to present such information in UI so that you can easily navigate and access the snapshot view of the project and also the historical versioning information? Put yourself in the position that you are using a tool like this everyday in your job like you are currently using SVN, SS, Perforce or any VCS system, what will contribute to the usability, productivity and effectiveness of the tool. I personally find the classical way for display folders and files like above are very restrictive and less effective for displaying deep nested logical models. Assuming that this is a greenfield project and not restricted by specific technology, how do you think I should best approach this? I am looking for idea and input here to add values to my research project. Feel free to make any suggestions that you think is valuable. Thanks again for anyone that shares their thoughts.

  Read the article

• When do you change your major/minor/patch version number?

  - by dave4351

  Do you change your major/minor/patch version numbers right before you release or right after? Example: You just released 1.0.0 to the world (huzzah!). But wait, don't celebrate too much. 1.1.0 is coming out in six weeks! So you fix a bug and do a new build. What's that build called? 1.1.0.0 or 1.0.0.xxxy (where xxxy is the build number of 1.0.0 incremented)? Keep in mind you may have 100 features and bugs to go into 1.1.0. So it might be good to call it 1.0.0.xxxy, because you're nowhere close to 1.1.0. But on the other hand, another dev may be working on 2.0.0, in which case your build might be better named 1.1.0.0 and his 2.0.0.0 instead of 1.0.0.xxxy and 1.0.0.xxxz, respectively.

  Read the article

• What "version naming convention" do you use?

  - by rjstelling

  Are different version naming conventions suited to different projects? What do you use and why? Personally, I prefer a build number in hexadecimal (e.g 11BCF), this should be incremented very regularly. And then for customers a simple 3 digit version number, i.e. 1.1.3. 1.2.3 (11BCF) <- Build number, should correspond with a revision in source control ^ ^ ^ | | | | | +--- Minor bugs, spelling mistakes, etc. | +----- Minor features, major bug fixes, etc. +------- Major version, UX changes, file format changes, etc.

  Read the article

• What are some ways people deploy relational database changes using Node.js? [closed]

  - by JamesEggers

  I've been diving more and more into Node.js and hosting services like Heroku and Nodejitsu recently and have been trying to figure out how to best deploy database changes for postgres or mysql. There are a few migration projects under npm that I can see; however, all seem to be really buggy or just not work. I currently manage the Monarch migration project on npm, but it's currently buggy itself and my experiences developing such utilities are in other, more procedural, languages. So what do people use to deploy changes to their databases on these environments? What has worked for people? I'm looking for a better understanding of what the current situation/process looks like.

  Read the article

• Storing revisions of a document

  - by dev.e.loper

  This is a follow up question to my original question. I'm thinking of going with generating diffs and storing those diffs in the database 'History' table. I'm using diff-match-patch library to generate what is called a 'patch'. On every save, I compare previous and new version and generate this patch. The patch could be used to generate a document at specific point in time. My dilemma is how to store this data. Should I: a Insert a new database record for every patch? b. Store these patches in javascript array and store that array in history table. So there is only one db History record for document with an array of all the patches. Concerns with: a. Too many db records generated. Will be slow and CPU intensive to query. b. Only one record. If record is somehow corrupted/deleted. Entire revision history is gone. I'm looking for suggestions, concerns with either approach.

  Read the article

• GitHub OS project how to have a good version and a work in progress version

  - by Para

  I have started my own OS application, I am hosting it on GitHub. My problem is that I push changes to the repository from more than one location so sometimes I want to work on it and sometimes I can't always finish something in time but I would still like to push it anyway so I can fetch it later from my other location. I'd like to be able to somehow have a stable version and have the master branch be a 'work in progress'. How do I do this? Is there some button I can push that will take the code from my master branch and make it into a zip file in my downloads tab and call it a version or should I do this by hand? Would it be better to have the master branch be nice and neat and have a separate branch to play with and then merge the two when the time is right? Would this not cause more problems in the merging phase?

  Read the article

• .NET asmx web services: serialize object property as string property to support versioning

  - by mcliedtk

  I am in the process of upgrading our web services to support versioning. We will be publishing our versioned web services like so: http://localhost/project/services/1.0/service.asmx http://localhost/project/services/1.1/service.asmx One requirement of this versioning is that I am not allowed to break the original wsdl (the 1.0 wsdl). The challenge lies in how to shepherd the newly versioned classes through the logic that lies behind the web services (this logic includes a number of command and adapter classes). Note that upgrading to WCF is not an option at the moment. To illustrate this, let's consider an example with Blogs and Posts. Prior to the introduction of versions, we were passing concrete objects around instead of interfaces. So an AddPostToBlog command would take in a Post object instead of an IPost. // Old AddPostToBlog constructor. public AddPostToBlog(Blog blog, Post post) { // constructor body } With the introduction of versioning, I would like to maintain the original Post while adding a PostOnePointOne. Both Post and PostOnePointOne will implement the IPost interface (they are not extending an abstract class because that inheritance breaks the wsdl, though I suppose there may be a way around that via some fancy xml serialization tricks). // New AddPostToBlog constructor. public AddPostToBlog(Blog blog, IPost post) { // constructor body } This brings us to my question regarding serialization. The original Post class has an enum property named Type. For various cross-platform compatibility issues, we are changing our enums in our web services to strings. So I would like to do the following: // New IPost interface. public interface IPost { object Type { get; set; } } // Original Post object. public Post { // The purpose of this attribute would be to maintain how // the enum currently is serialized even though now the // type is an object instead of an enum (internally the // object actually is an enum here, but it is exposed as // an object to implement the interface). [XmlMagic(SerializeAsEnum)] object Type { get; set; } } // New version of Post object public PostOnePointOne { // The purpose of this attribute would be to force // serialization as a string even though it is an object. [XmlMagic(SerializeAsString)] object Type { get; set; } } The XmlMagic refers to an XmlAttribute or some other part of the System.Xml namespace that would allow me to control the type of the object property being serialized (depending on which version of the object I am serializaing). Does anyone know how to accomplish this?

  Read the article

• versioning & store vm image

  - by zeroin23

  How would you store many vm images and versioning it? SVN bindiff is slow i think....

  Read the article

• Good resources for versioning...

  - by stephmoreland

  I have a number of Windows servers at work that are used for staging web sites for clients while they are being created. I wanted to start using versioning on them so that when we work with outside vendors on a project, if/when they overwrite my work, I'd like to be able to go back and get the version before. My question is that I think I'm not looking for the correct terms in searching for information, but what kind of resources are there to learn how to install the software for versioning or a site to help me get started. Any and all suggestions would be appreciated. Steph

  Read the article

• Is it really wrong to version documents using CouchDB's default behaviour?

  - by Tomas Sedovic

  This is one of those "I know I shouldn't do this but it's oh so convenient." questions. Sorry about that. I plan to use CouchDB for storing a bunch of documents and keeping their entire revision history. CouchDB does the versioning automatically, but it is strongly discouraged for programmer's use: "You cannot rely on document revisions for any other purpose than concurrency control." From what I've found on the CouchDB wiki, the versions can get deleted either during compaction or during replication. As far as I can tell, Compaction must always be triggered manually and Replication occurs only when there's more than one database server. The question is: if I won't run compaction and will use only single database instance for my documents, can I just use CouchDB's document versioning and expect it to work? What other problems I might run into? E.g. does not running compaction hurt the performance or consume significantly more disk space (than if I did handle the versioning manually)?

  Read the article

• Is it really wrong to version documents using CouchDB's behaviour?

  - by Tomas Sedovic

  This is one of those "I know I shouldn't do this but it's oh so convenient." questions. Sorry about that. I plan to use CouchDB for storing a bunch of documents and keeping their entire revision history. CouchDB does the versioning automatically, but it is strongly discouraged for programmer's use: "You cannot rely on document revisions for any other purpose than concurrency control." From what I've found on the CouchDB wiki, the versions can get deleted either during compaction or during replication. As far as I can tell, Compaction must always be triggered manually and Replication occurs only when there's more than one database server. The question is: if I won't run compaction and will use only single database instance for my documents, can I just use CouchDB's document versioning and expect it to work? What other problems I might run into? E.g. does not running compaction hurt the performance or consume significantly more disk space (than if I did handle the versioning manually)?

  Read the article

• WYSIWYG editor for structured text (suitable for SVN versioning)

  - by chris_l

  I'm looking for an open source cross platform WYSIWYG editor that I can use to write documentation. I'm not looking for a web based solution - i.e. it should work without a web server, and I want to save my files directly to disk. The result could be any structured format, like Wiki markup, ReStructuredText, DocBook, or a small subset of HTML, ... But it's important, that Subversion diff can be used to see differences between the versions easily (this wouldn't work with .odt or .rtf files for example) I'm currently thinking about using Open Office, and saving the files as HTML, but is there a better solution?

  Read the article

• nginx rewrite regex for API versioning

  - by MSpreij

  What I want is for the first to be turned into the second.. /widget => /widget/index.php /widget/ => /widget/index.php /widget?act=list => /widget/index.php?act=list /widget/?act=list => /widget/index.php?act=list /widget/list => /widget/index.php?act=list /widget/v2?act=list => /widget/v2.php?act=list /widget/v2/?act=list => /widget/v2.php?act=list /widget/v2/list => /widget/v2.php?act=list v2 could also be v45, basically "v\d+" act, "list" in this case, can have many values and more will be added. Any additional query parameters would just be passed on with $args, I guess. Basically URLs not specifying the version will go to index.php, which can then decide what specific version file to include. What I am afraid of happening is loops - this should sit in location /widget { right?. (As for putting the version of the API in the URL, I'm not trying to be RESTful, and target audience is small) Resources on how to do this entirely in index.php using "routers" also welcome :-/

  Read the article

• wamp and xamp Php versioning

  - by Pennf0lio

  Hi, I need advice installing XAMPP with different php versions. How can I install XAMPP supporting different version of php? Before I formated my computer I used both WAMP and XAMPP for specific purposes. I used XAMPP because some of the scripts are buggy when run in WAMP, I used WAMP because it support different versions of PHP. Now I want that feature that support different version of PHP to be added to XAMPP. So I could just install 1 software for my Web Development and It would be easy for me to manage. If this is not possible can you give me an alternative solutions? Thanks Note: I'm running on Windows 7

  Read the article

• Workflow: suggest a versioning and file control for Designer and Developer

  - by Pennf0lio

  Our company are having hard time managing project files and managing versions of PSD, HTML, PHP, and CSS files. Can anyone recommend a good software or workflow to handle files and versions. Here's my common scenario: I work for a project in my computer, it could be a Website mockup or a coding project. I then save all the files locally in my workstation. I'll then upload all the project files in the server connected in our network to have a backup. In my files, I usually append a "r1" for revisions, like "WebsiteMockup_r1" or "WebsiteMockup_r2". I need somehow to synchronize all my local files to the server and have some versions options.

  Read the article

• File versioning software

  - by blade7

  Hi, I am looking for some software which can version control all my files on my OS (For Windows Server). So I can go back to a file 5 versions old. I know Genie can do this but I have BackupAssist for backups which Genie also does. I need an app that just offers the above.

  Read the article

• Source Versioning for Visual Studio Express

  - by Mike Wills

  Is there any Visual Studio Express plug ins for source versioning? I am starting a project on my own and only have the Express version of Visual Studio 2008.

  Read the article

< Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >