FWIW, +1.
Ben
- Original Message -
> From: Hausmann Simon
> To: Thiago Macieira ; "development@qt-project.org"
>
> Cc:
> Sent: Friday, September 28, 2012 4:22 AM
> Subject: Re: [Development] Branching for Qt 5 repositories
>
>
> Sounds g
"stable" and "release" are too similar in meaning and might cause
confusion. Debian's naming scheme: unstable(or dev is
fine)/testing/stable is easier to understand at a glance. KISS
Keeping the word "master" out is a good idea though... since it's what
git defaults to and doesn't really tell you
I think so, so I have to keep silent anymore.
2012/9/28 Stephen Kelly
> Unfortunately there's no chance of changing it, I'm sure.
--
*Please don't ask where I come from, It's a shame!*
Best Regards
Yuchen
___
Development mailing list
Development@q
On Friday, September 28, 2012 12:37:23 Loaden wrote:
> I prefer:
> dev -> next
> stable -> master
> release -> release
Me too. It's what git.git does and it's close to what cmake does.
Unfortunately there's no chance of changing it, I'm sure.
Thanks,
--
Stephen Kelly | Software Engineer
KDAB
From: development-bounces+andre.poenitz=digia@qt-project.org
[development-bounces+andre.poenitz=digia@qt-project.org] on behalf of
Loaden [loa...@gmail.com]
> I prefer:
> dev -> next
> stable -> master
> release -> release
-1, and +1 for the originally proposed version. For someone wanti
Thiago Macieira wrote:
> On sexta-feira, 28 de setembro de 2012 09.06.42, Laszlo Papp wrote:
>> > That's the point: it's not the most common way, at least not in Git. If
>> > you
>> > take for example Git's Git, the "master" branch contains the latest
>> > release, whereas the next release is in th
> I actually prefer Loaden's suggestion,
Ok for me.
> Yeah, right... We've been feature-complete for a while. So why is Qt 5.0.0 not
> released yet?
[skip]
Yes, I am sorry for that. I did not get your point initially, but I
understand your point now (see my other email).
> We cannot design an i
On sexta-feira, 28 de setembro de 2012 10.28.26, João Abecasis wrote:
> No it is not a release. The point is features are developed outside
> shared branches until the point where they are ready for wider
> exposure. It doesn't mean they won't change. But it does mean the
> feature does something u
On sexta-feira, 28 de setembro de 2012 09.06.42, Laszlo Papp wrote:
> > That's the point: it's not the most common way, at least not in Git. If
> > you
> > take for example Git's Git, the "master" branch contains the latest
> > release, whereas the next release is in the "next" branch.
>
> Well, yo
Laszlo Papp wrote:
>> No, I really do and those qualifiers are required, but note that they apply
>> to
>> each feature individually. That is, if you want to merge the command-line
>> parser, it needs to be feature-complete, working, documented, tested and a
>> few
>> more qualifiers (cf. Qt Proj
> If those all fully apply, I would call it "release" since there is
> nothing to fix anymore or stabilize since it is "completely". My point
> is that there may be bugs on certain platforms where it is not well
> tested, or the documentation is written and approved by developers and
> cannot get b
, September 27, 2012 11:46 PM
To: development@qt-project.org
Subject: [Development] Branching for Qt 5 repositories
Hello
A few weeks ago I met with Lars, João, Sinan, Sergio A., Jędrzej and a few
others and we discussed the branching for the Qt 5 repositories. This,
therefore, does not apply to Qt
> That's the point: it's not the most common way, at least not in Git. If you
> take for example Git's Git, the "master" branch contains the latest release,
> whereas the next release is in the "next" branch.
Well, you can say that it is not common, but I could enumerate quite a
few examples inclu
On 09/28/2012 07:37 AM, Loaden wrote:
> I prefer:
> dev -> next
> stable -> master
> release -> release
+1
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists
On sexta-feira, 28 de setembro de 2012 00.54.34, Laszlo Papp wrote:
> > They are:
> > - dev: unfrozen branch, containing alpha-quality[*] code that is ready to
> > go>
> >into beta testing at any time
>
> What is the reason for calling this "dev" instead of "master" which is
> more common for
At lease, I think the 'dev' is not a good name for remote branch.
Does it mean the other branch is in no--active-developing state?
I prefer using 'feature' instead. All the new feature should go 'feature'
branch.
and the 'stable' is only bug fix branch.
2012/9/28 Lincoln Ramsay
> Luckily we use
On 28/09/12 14:37, Loaden wrote:
I prefer:
dev -> next
stable -> master
release -> release
Clearly they should be named after a traffic light:
green - commit away
orange - be careful (keep it stable)
red - don't commit
Luckily we use git so you can give the branches any name you want on
yo
I prefer:
dev -> next
stable -> master
release -> release
>next
-->master
-->release
2012/9/28 Laszlo Papp
> > They are:
> > - dev: unfrozen branch, containing alpha-quality[*] code that is ready
> to go
> >into beta t
> They are:
> - dev: unfrozen branch, containing alpha-quality[*] code that is ready to go
>into beta testing at any time
What is the reason for calling this "dev" instead of "master" which is
more common for developers, and it would not have an impact on the
submitted changes to gerrit even
19 matches
Mail list logo
