And I almost always do it exactly the opposite, I develop on trunk then backport via svn merge.... Shawn's comments are well taken though assuming 5x is closest to what you're actually using.
But it doesn't matter that much to you because you can't commit anyway so pick whichever one is most convenient. Whichever committer picks up your changes will be responsible for merging the two, you don't need to provide separate patches. One thing to note though. It's actually a rather a common practice to check code in to trunk and let it "bake" for a few days before backporting for any "risky" changes although there's no real definition of "risky". As far as JIRAs are concerned, the "how to contribute" page talks about those, you just have to register with the system before you can add/edit them. I'd suggest, if you do raise a JIRA, to describe at a high level what you're thinking of doing _before_ you spend the time to code. It may turn out that your idea won't work for some reason, and getting that kind of feedback early may save you some work. Best, Erick On Tue, Mar 31, 2015 at 11:34 AM, luqman ulkhair <[email protected]> wrote: > Thank you Shawn for your suggestion. > Regards > > On Tue, Mar 31, 2015 at 11:28 PM, Shawn Heisey <[email protected]> wrote: >> >> On 3/31/2015 11:48 AM, luqman ulkhair wrote: >> > Thanks Gora,Can you please tell me should I checkout trunk or >> > branch?How does the development process work in asf? >> >> In terms of commits, we almost always commit first to trunk, then >> backport to any branches that will also receive the change. >> >> I personally tend to do most of my actual development work in the stable >> release branch, which is currently branch_5x ... then I will make a >> patch and make sure it applies successfully to trunk before running >> precommit and actually committing. I do things this way because I'm >> almost always doing work that will affect the next minor release. For >> work that will not be backported into the stable branch, it makes a lot >> of sense to start with trunk. >> >> By developing and testing in the stable branch first, I am more likely >> to find problems that could affect current users. If comprehensive >> testing of the change is done in trunk, there might be subtle bugs that >> only appear when the change is backported. If my changes are going to >> break things when applying the patch to a different branch than it was >> developed on, I'd much rather have that happen in trunk than the stable >> branch. >> >> I think that most of the time an end-user should be developing on the >> stable branch just like I do, because it's the most up-to-date code >> that's closest to the version they're actually running. Some parts of >> trunk are wildly different than the stable branch. >> >> Thanks, >> Shawn >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
