search

symphonycms / remote_datasource

An improved datasource to fetch data from TXT, CSV, XML and JSON sources.
Other
14 stars 9 forks source link

Version 2.1 #24

Closed nitriques closed 10 years ago

nitriques commented 10 years ago

Fixed the readme version. Sorry about that.

nitriques commented 10 years ago

A damn, should I commit it to integration ?

nilshoerrmann commented 10 years ago

I'm actually keen of removing the integration branch, moving on with feature branches.

nitriques commented 10 years ago

Hum. Integration is a nice place to merge feature branch since it permits to have 'staging' code. Code that has been merge but don't need releasing until some time or until another feature branch is merged.

Losing that means that we must create a new version each time a PR is merged, in order to maintain the same level of feature is a released version.

But, I leave this decision to you guys since you are managing the repo, I just wanted to mention that doing so has a caveat.

nilshoerrmann commented 10 years ago

Losing that means that we must create a new version each time a PR is merged

You'd just have to rebase your feature branch.

Having only a master branch plus additional feature-* branches conforms to the Github flow this whole system is built around.

nitriques commented 10 years ago

You'd just have to rebase your feature branch.

Yeah I understand that. But I like to be able to merge one or more PR into an integration branch BEFORE releasing a new version. Merging PR into master means every PR should creates a new version since merging creates a new 'release'.

In the end, I do not really care since its really more a choice the maintainers have to do.

nilshoerrmann commented 10 years ago

If you work feature base, it makes sense to release a new version on merge. If it's combined with semantic versioning you'll get a very clear version and feature classification: you'll release more compact versions, you'll release more often but the users always know on which level you did change things (changing concepts, adding to concepts or fixing concepts).

nilshoerrmann commented 10 years ago

By the way, I really think that it's a big problem that we put too much in the integration branch before releasing a version. Most people around here use the integration branches directly because it takes too long until features land in master.

nitriques commented 10 years ago

Most people around here use the integration branches directly because it takes too long until features land in master.

Yeah that's a problem too. There is no perfect solution, only trade-offs.

nitriques commented 10 years ago

Sorry I just saw your earlier post...

If it's combined with semantic versioning you'll get a very clear version and feature classification: you'll release more compact versions, you'll release more often but the users always know on which level you did change things

I agree this is good. If you are willing to maintain it this way, I have no problem with that. If releasing frequently is a problem, then the integration branch makes sense. If not, then it does not have any purpose than.