Contributors mailing list archives
Re: Confusion about branch 9.0 in githubby
I concur with Rafael's recommendation of making 8.0 the default branch. Many people start by browsing Github and where they start makes a strong impression.
I would also say that V9 itself should be renamed to V9-DEV (or similar) and not change till either a BETA or RC version.
Of course the constant state of change complicates this, but it would help "end users" and minimize support type explanations of what is working and what is not.
Also, use Github Wiki for ongoing documentation about status of the whole project and its process.
My thoughts anyway.
You consider that a migration is a 2 commits work which is silly if the addon is a bit elaborated.
A unique commit for a migration seems utterly wrong to me in many situations.
I will never ever migrate 'connector' or 'magentoerpconnect' in one commit. Even smaller addons I wouldn't, when you work on a migration, you often have to make choices, for instance when you fix a bug or when you have to change a feature, this is in the commits that it should be documented and you shouldn't mix them all.We **must not** break good commits practice just because some users are confused because they don't read a readme file.On Fri, Nov 13, 2015 at 11:53 AM, Daniel Reis <firstname.lastname@example.org> wrote:Guewen, there is a solution for the review diff: Ask the author to do the migration work in a single commit, and then review only that commit instead of the full diff. Personally, there are times where I want to review untouched parts of the code, so if a also have the full module diff I would find that useful. In a nutshell: - For authors, the work to port from 8.0 to 9.0 is about the same in each solution (see Pedro's link). - For reviewers, focusing in the migration changeset commit solves the review effort issue. - For "end users" it is clear about what modules are available. /DR
Post to: mailto:email@example.com