flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Iwo Banaƛ <banas....@gmail.com>
Subject Re: Committer duties and information
Date Wed, 04 Jan 2012 21:35:34 GMT
Hi Guys,

I think that the crucial question here is how we handle version control.
For a simple bugfix committing to "trunk" and voting or submitting a
patch are OK.
The problem is how we handle bigger chunks of work like mentioned TabNavigator?

I'm all for collaboration from the very beginning of feature
implementation rather then submitting a huge patch with "finished"
component. However this requires some standardised branching strategy
(e.g. feature branches for components).
Git is really helpful for this kind of collaboration (easy
branching/merging/cherry-picking...) but I understand that Apache Git
is just a read only snapshot of SVN. Is that right?

Would it be possible to work in the opposite direction i.e.
collaborate in Git and then commit to SVN?

The other aspect of version control would be agreeing on the planed
releases and backward compatibility approach.
I guess that soon we'll be working simultaneously on not fully
backward compatible changes targeting Flex 5 and bugfixes for Flex
4.7.
Probably it'd make sense to start a separate thread to discuss
branching/versioning.

+1 for modularity, if we get it right it can not only make
collaboration easier but also help in improving performance.

Cheers,
Iwo Banas


On 4 January 2012 20:39, Greg Reddin <gredbug@gmail.com> wrote:
> Better yet would be to merge them. Hopefully no one will be off
> working on stuff in a vacuum then try to commit it all at once.
> Hopefully that work will be done here in bits and pieces. If two
> people have different ideas of what a TabNavigator component should be
> then we should discuss those different ideas on list and see if we can
> come up with a component that works for both parties.
>
> Greg

Mime
View raw message