Search Results

Search found 7 results on 1 pages for 'linquize'.

Page 1/1 | 1 

• Bump version before kicking off new development or when tagging a release, which is better?

  - by linquize

  Some projects bump version before kicking off a new development, while the other projects bump version when tagging a release. Which approach is better? If version number not changed at the start of new phase, the developers may forget to change it and simply release the program. If version number changed before tagging release, then 2 the version numbers (tag and Makefile/AssemblyInfo.cs) do not match. git describe may give you v1.2.3.4-15-g1234567 if current revision is after v1.2.3.4, but you have already changed the files to have v1.2.3.5

  Read the article

• How to discriminate commented code and documentation comments

  - by linquize

  After using version control tools, it is no longer necessary to comment out old code. However, some team members still comment out old code. Therefore, I want to clean them up. I want to mark commented lines which are really comments / documentation, so that every time I do not need to re-read all commented regions. The unmarked lines left are new commented code. How do I achieve this? Any existing tools or need to write on my own? Similar concept: in git, we have 'partial commit' to select some lines to commit. However, the lines marked in 'partial commit' is valid once only.

  Read the article

• Parsing stdout with custom format or standard format?

  - by linquize

  To integrate with other executables, a executable may launch another executable and capture its output from stdout. But most programs writes the output message to stdout in custom format and usually in human readable format. So it requires the system integrator to write a function to parse the output, which is considered trouble and the parser code may be buggy. Do you think this is old fashioned? Most Unix-style programs do that. Very few programs write to stdout in standard format such as XML or JSON, which is more modern. Example: Veracity (DVCS) writes JSON to stdout. Should we switch to use modern formats? For a console program, human readable or easy parsable: which is more important ?

  Read the article

• Encourage the use of markup files as documentation in enterprise [closed]

  - by linquize

  To make it eaiser to do version control and diff files of documentation, use markup files, such as HTML: html/xhtml, XML: docbook, Wiki: markdown to replace doc/docx. docx is too complex and lengthy. For html, no extra document generation required. Programmers can write html directly and end users / managers can use any web browsers to view the document. For custom XML or Wiki formats, viewers are required to view the document or converters are used to export to pdf/doc. Is such move becoming popular in enterprise context? Why or why not?

  Read the article

• Why do some open source projects do not allow to report issues in a public issue tracker?

  - by linquize

  Why do some open source projects do not allow to report issues in a public issue tracker? Those projects requires the issues to be reported via email, and the issues may be forwarded to people in mailing list. Users may repeatedly report the same issue if there is no public issue tracker, as they have no easy way to know what have been reported before. The project team members need to spend extra time answering those repeated issues. Some projects do have a public issue tracker, but the issues are still reported through email and they are posted only by the project team only after filtering. It does not allow anyone to report directly in issue tracker. (example: SVN) Such arrangement is not transparent nor open, which I think it violates the philosophy of open source. And it is outdated.

  Read the article

• Why do some open-source projects NOT have a public issue tracker?

  - by linquize

  Why do some open source projects not allow to report issues in a public issue tracker? Those projects require the issues to be reported via email, and the issues may be forwarded to people in a mailing list. Users may repeatedly report the same issue if there is no public issue tracker, as they have no easy way to know what has been reported before. The project team members need to spend extra time answering those repeated issues. Some projects do have a public issue tracker but the issues are still reported through email and they are posted by the project team only after filtering. It does not allow anyone to report directly in issue tracker (example: SVN). Such arrangement is not transparent nor open, which I think violates the philosophy of open source. And it is outdated.

  Read the article

• Metro-style / iPhone apps development too demanding for newbie developers? [closed]

  - by linquize

  Both Metro-style and iPhone app require approval and publishing to app store. And they focus most on user interface and the quality of the software. Developers must deal with technical aspects, such as async programming (no UI blocking), no console program (must design a UI that cope with "Standard"), no CPU hungry (pause app if deactivated), need to study the permission matrix (not full access right), and more ... A newbie is not familiar with threading and synchronization. Do you thick they are too demanding for newbie developers? Can you give more examples how demanding it is?

  Read the article

1