Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
While using Gitflow, what is the reason for separating branch naming to feature vs bugfix vs hotfix?
I.e. why not just, for example, instead of:
feature/
bugfix/
hotfix/
Just do:
change/
What does separating by feature/bugfix/hotfix buy?
Great questions and the answer really depends on how you sort your git. The branching model and gitflow in general is trying to give us some order in the chaos that commits are just after a couple of days.
The image below shows you what they though makes most sense.
(As far as I know it all came from this blog post by Vincent Driessen)
Separating your hotfixes which merge directly into master and your bugfixes which merge into dev makes it easier to go with your product cycle.
The idea is you build your app, create features, make a release candidate (beta test) and then release your app. Hotfixs can be necessary at any time after this. No point in going back all the way to the feature branch and issuing a bug fix there as the feature may already been developed further.
Does that make sense?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have experience with Sequelize and TypeORM. LoopBack looks like a good alternative, so I tested it. But it looks like LoopBack 4 is not a finished product; it barely has the needed features for a production application.
My question is: why the LoopBack team decided to publish an unfinished product?
there are a lot of companies and products on live using Loopback4.
Which features you missed from the new version?
I mean, the product is free, open source and built off of previously released, finished products. Releasing it allows them to both test functionality and be provided with feedback and aid in building the actual application. Lots of products are released before they are finished for these important reasons. If you read the documentation, it is a community built product.
Most frameworks are constantly being updated to add functionality, so 'finished' is not really a word that can be thrown around for a framework
While it is not finished, to say it barely has the needs to support a production application is very dependent on the type of application being built.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Rakudo Star is a release targeted towards end users (if I'm not mistaken). As such, it includes a number of useful modules that can be used in a wide range of projects.
But how does the team behind it decide which modules to include? Do module developers talk to them and ask for inclusion, or do they look at usage statistics and include the most popular? Or is inclusion completely arbitrary?
What process should one go through to get their module included?
The collection of modules is in the star repository, includes as sub-modules of the repo. I haven't seen any kind of description of what modules are installed there and why, but I guess using the issues and/or pull requests is the way to go. In fact there's this closed issue which points in that direction, including a reference to ecosystem statistics, so I guess regarding your three questions.
There's no established procedure that I have been able to see.
Apparently, they look at statistics, after some developer asks for them.
I don't think that's the case. They at least have to pass all the tests in all platforms to be included. Also, I don't think my evolutionary algorithms module will be included any time soon.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Just to be clear, I'm not asking how to add dependencies in a README.md, but rather, how to handle documenting them given my situation.
Looking at the SO Help Center, I saw this as "a practical, answerable problem that is unique to software development," and I thought it appropriate to ask here.
I need some guidance on a project. To summarize... The project is a technology prototype for a small business, which I'll call "ACME," which contracted with me, and is using Raspberry Pis as a distributed client network to provide a service to their customers. The ACME's owner is not technical. He emphasized simplicity, extensibility, and stability for the project, and I want to avoid unnecessary confusion.
Where I'm becoming concerned is that while my direct dependencies are few, about two or three, my sub-dependencies are numerous. (To clarify, I'm coding the project in Node.js, with the exception of a few small C++ worker programs.) The modules I'm working with collectively sum up to about 40 sub-dependencies or greater.
The most important thing to me is to do the right thing, especially with this being my first official job as a developer, and I'm all on my own with no senior developer to advise.
So... should I only list my direct dependencies (which I would prefer, and which handle documenting their dependences themselves), or list all dependencies?
npm can list your dependencies just fine by itself (npm ls). What you need to document is how to get the system up and running, both as a user and as a developer (your successor or yourself in the future when you need to restore your dev setup from scratch).
EDIT: Additionally you will want to document how your own programs fit together as components in the whole system.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
So, I working on a problem at my workplace, that is a big company with a serious CNC shopfloor. Here I thought I could make the life much easier with a little software. I have the conception, I put a lot of work in it together with my helpful friends and here is the point, when I suppose to explain it to my leaders.
The problem is, I've never made anything like this before. So I don't know the way. I should use UML-diagrams and use cases, class diagrams etc? Or which is a preferred way?
Out of the management perspective you could explain why your programm is efficient and required to optimise the workflow. Creating a presentation could help you make the idea of the application clear and bring it in a form which is understandable.
If I were you I will go in priorities for activities diagram. You create an activity diagram of the old flow and another with the new flow. You show both to your manager and you compare them. Normally your program will minimise steps inside the new flow. Then you can say that with less steps to manage there will be more money to earn for your manager and you at the end :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
In software developement project..
While preparing a gantt chart, which things we should take care?
A very vague question, kind of like "What is the meaning of life?".
Things that occur to me:
Knowing what you will build
the order in which things have to be build,
resources required,
when things have to be finished,
who will have to check the build items,
when are people and resources available.
The WBS 100% rule (see this)
Where relevant, use abstract time units in the chart and scale to meet a fixed release date.
Don't overuse. Use it for what it's good for. For example, avoid showing too many dependencies: Draw out a separate dependency tree
If you have several tasks which are proving difficult to estimate then try to have them run in parallel. That way you reduce the overall risk should one or more of them overrun.