Just a few comments, from someone who's been releasing software for nearly 30 years.
I don't recommend releasing software from an IDE, because you don't have enough control over IDE settings and behavior. That setting you tweak today for this or that test, may make it into the product as a change. I've seen it happen many times. The problem is worse when you have a team of people, and each person's IDE may be configured differently, but you today and you 6 months from now may not be the same, either. And Eclipse's build process is completely opaque. There are a lot of settings, some of which affect the build, but there's no one place you can go to see, "these are the steps being performed, and these are the settings that affect the build". I always insist on total automation of production builds. Your strategy of merging to release projects from trunk is a quite viable one, and one I considered, but I ended up going in a different direction. Yours has the disadvantage of maintaining multiple projects, which can be a bit of a pain when editing -- which project am I editing now? The potential for merge conflicts also makes automating the release process potentially failure-prone, but that should be a rare problem, since you probably won't be changing that much in your release projects. But semantically, your merge step and my configuration step are doing the same job. I only have to pull it down from the server once, as my configuration step is local. Your approach has the advantage that you can inspect the result without performing a build. When I write up my build process, I'll try to make it clear how this alternative fits in, and the trade-offs, so people can choose what suits them. The key things in any such strategy is that it shouldn't involve manual steps, not just to save labor, but for reliable repeatability. And it should leave a clear audit trail in the revision control system. On Apr 6, 6:15 am, Eddie Ringle <[email protected]> wrote: > I use a Git repo to manage all of my project's code. I store the meat > of the code on GitHub, while I have local 'free' and 'donate' > branches, each with slight modifications of their own. When the time > comes to get a new release ready, I just merge the changes from the > master branch into each of these local branches, fixing merge > conflicts as they appear. Then I just export the application using > Eclipse and I'm good to go. > > On Apr 5, 11:37 pm, Marc <[email protected]> wrote: > > > > > I used to be a C/C++ programmer before getting in to android. I am not > > sure how people maintain 2 versions of a program without using #ifdef > > preprocessor macros. Right now I am changing the package name in > > eclipse and changing the code manually, but this seems really > > inefficient. Can anybody suggest a good way of having 2 or more > > projects that share most of the code? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using "remove me" as the subject.
