My app is done and I'm pretty happy with it. There are some pretty major features I would like to add and I expect there will be as-yet-undiscovered-bugs. How do people deal with workflow to address those things?
My thinking is that I currently have version X of the app. I'll use this to start building new features and so soon version X will be Version Y.
However, if there are easy to fix bugs, I would like to fix those immediately rather than waiting for the new features to be ready. So when I do that I can fix version X and then upload version X.w to Google Play, but then version Y will still have the bug. I guess I can try matching every change made in X in Y, but that seems like asking for something to get missed or messed up along the way, especially when fixes are complicated.
I'm sure this is something people who actually know about programming deal with all the time. How do they/you deal with it?
My thinking is that I currently have version X of the app. I'll use this to start building new features and so soon version X will be Version Y.
However, if there are easy to fix bugs, I would like to fix those immediately rather than waiting for the new features to be ready. So when I do that I can fix version X and then upload version X.w to Google Play, but then version Y will still have the bug. I guess I can try matching every change made in X in Y, but that seems like asking for something to get missed or messed up along the way, especially when fixes are complicated.
I'm sure this is something people who actually know about programming deal with all the time. How do they/you deal with it?
--
there is no built in version control system for your App Inventor app, you have to do that manually
--
Alexandra M asked how to manage two versions of her app, one for release with bugfixes and another for new feature development. This is asking how to do version control with AI2. As she suspects, there are standard ways software developers do this. Several version control systems exist that are nearly independent of the language being used. Git and mercurial are two examples, but they all have similar ideas -- and learning curves. There is the "checkpoint" feature you could use in AI2 for a simple solution. Taifun pointed out that the AI2 development environment doesn't offer much else beyond that to help you manage version control, so you have to do it yourself. But what is it that you should do yourself?
A version control system keeps track of what changes or versions were made, by whom, when, and from what earlier version. Good version control systems offer mechanisms for describing each version's improvements. Saving both the old and new version is sufficient for keeping track of what changes were made. If you use the "save as" or "checkpoint" feature of AI2 every time you make an improvement, your project list will quickly get messy. As a curriculum writer for Project Lead The Way teaching students about software development, I'm interested to hear how teachers are handling this with AI2. We expect student teams in elementary, middle and high schools (the latter two of which are using AI2 along with other development platforms) to maintain intermediate versions and to document their process of incremental improvements. I have a recommendation for AI2 users, but would appreciate discussion of what is working for others.
Here's my recommendation. Think of each AI2 project in the web interface as the leading edge of a branch. In Alexandra's case, she would have two AI2 projects in the web interface: one version that has been released and updated with bugfixes, and a second version for the development of a new feature. When a bug is found, update both projects with the fix. Download the AIA files and keep the record of what versions came from what earlier versions in the filename. Example:
In AI2 website:
⦁ my_cool_app_release_v1
⦁ my_cool_app_development_v2
On your computer, in a folder my_cool_app:
⦁ my_cool_app_release_v1.01.AIA
⦁ my_cool_app_release_v1.02.AIA
⦁ my_cool_app_release_v1.03.AIA
⦁ my_cool_app_development_v2.01.AIA
⦁ my_cool_app_development_v2.02.AIA
⦁ my_cool_app_development_v2.03.AIA
⦁ my_cool_app_development_v2.04.AIA
⦁ my_cool_app_development_v2.05.AIA
Keep documentation of what those versions accomplished either in a paper project notebook (comp books work great) where you can write lots of text, draw figures, brainstorm ideas, and record business plans, graphics designs, observations of user testing and client meetings. Alternatively, you could append what might be described as a "commit message" directly to the file name. I don't like that option because it would have to be so brief and would need underscores instead of the spaces, quotes, and commas you'd like to use in descriptors. I suppose you could use spaces but change them before uploading an AIA if you ever wanted to go back and look at an earlier version. It would look like this in your local machine's project folder:
⦁ my_cool_app_release_v1.01_initial release
⦁ my_cool_app_release_v1.02_fix misspelling
⦁ my_cool_app_release_v1.03_fix crash from array index out of bounds
⦁ my_cool_app_development_v2.01_duplicates v1.01
⦁ my_cool_app_development_v2.02_add a destroy NSA data button
⦁ my_cool_app_development_v2.03_fix misspelling fast forwards to v1.02
⦁ my_cool_app_development_v2.04_implement NSA login with button
⦁ my_cool_app_development_v2.05_fix crash from array index out of bounds ff v1.03
If collaborating with someone, you could put the downloaded AIA files in a shared location (e.g. Google Drive) and append initials to indicate the author of that "commit." Version control systems have tools for merging the work of two people, and in this case you're really out of luck and it will become difficult to know whether v2.03BB came from 2.01BB or from 2.02SP unless you make your filename conventions more convoluted to handle that version control issue.
What other workflows do people use to manage version control with AI2? What experiences do you have implementing these with students at various ages? Anyone doing version control when multiple AI2 developers collaborate?
A version control system keeps track of what changes or versions were made, by whom, when, and from what earlier version. Good version control systems offer mechanisms for describing each version's improvements. Saving both the old and new version is sufficient for keeping track of what changes were made. If you use the "save as" or "checkpoint" feature of AI2 every time you make an improvement, your project list will quickly get messy. As a curriculum writer for Project Lead The Way teaching students about software development, I'm interested to hear how teachers are handling this with AI2. We expect student teams in elementary, middle and high schools (the latter two of which are using AI2 along with other development platforms) to maintain intermediate versions and to document their process of incremental improvements. I have a recommendation for AI2 users, but would appreciate discussion of what is working for others.
Here's my recommendation. Think of each AI2 project in the web interface as the leading edge of a branch. In Alexandra's case, she would have two AI2 projects in the web interface: one version that has been released and updated with bugfixes, and a second version for the development of a new feature. When a bug is found, update both projects with the fix. Download the AIA files and keep the record of what versions came from what earlier versions in the filename. Example:
In AI2 website:
⦁ my_cool_app_release_v1
⦁ my_cool_app_development_v2
On your computer, in a folder my_cool_app:
⦁ my_cool_app_release_v1.01.AIA
⦁ my_cool_app_release_v1.02.AIA
⦁ my_cool_app_release_v1.03.AIA
⦁ my_cool_app_development_v2.01.AIA
⦁ my_cool_app_development_v2.02.AIA
⦁ my_cool_app_development_v2.03.AIA
⦁ my_cool_app_development_v2.04.AIA
⦁ my_cool_app_development_v2.05.AIA
Keep documentation of what those versions accomplished either in a paper project notebook (comp books work great) where you can write lots of text, draw figures, brainstorm ideas, and record business plans, graphics designs, observations of user testing and client meetings. Alternatively, you could append what might be described as a "commit message" directly to the file name. I don't like that option because it would have to be so brief and would need underscores instead of the spaces, quotes, and commas you'd like to use in descriptors. I suppose you could use spaces but change them before uploading an AIA if you ever wanted to go back and look at an earlier version. It would look like this in your local machine's project folder:
⦁ my_cool_app_release_v1.01_initial release
⦁ my_cool_app_release_v1.02_fix misspelling
⦁ my_cool_app_release_v1.03_fix crash from array index out of bounds
⦁ my_cool_app_development_v2.01_duplicates v1.01
⦁ my_cool_app_development_v2.02_add a destroy NSA data button
⦁ my_cool_app_development_v2.03_fix misspelling fast forwards to v1.02
⦁ my_cool_app_development_v2.04_implement NSA login with button
⦁ my_cool_app_development_v2.05_fix crash from array index out of bounds ff v1.03
Your versions in the AI2 web server would be "ahead" of 1.03 and 2.05, with partial improvements. When you're feeling good about your improvements, save on the server like normal but then also download the AIA files and give them a version number in the filename and either an entry in your project notebook or as short text appended to the filename.
When you're ready to release that new feature on the Play Store with my_cool_app_development_v2.102, (and have come to wish that you had named that first one v2.001 so that it all got alphabetized nicely in Windows explorer), you could duplicate that file as my_cool_app_release_v2.01 so that your user base is ignorant of your development branch numbering and only sees bugfixes from there forward on version 2. Another standard thing to do would be let the release be numbered v3.01 and keep odd numbered versions as releases and even numbers as development.If collaborating with someone, you could put the downloaded AIA files in a shared location (e.g. Google Drive) and append initials to indicate the author of that "commit." Version control systems have tools for merging the work of two people, and in this case you're really out of luck and it will become difficult to know whether v2.03BB came from 2.01BB or from 2.02SP unless you make your filename conventions more convoluted to handle that version control issue.
What other workflows do people use to manage version control with AI2? What experiences do you have implementing these with students at various ages? Anyone doing version control when multiple AI2 developers collaborate?
--
댓글 없음:
댓글 쓰기