Interestingly, there will be heavy updates to these documents and hence will be updated rigorously. Going with links to history I think won't work in this case. We'll need to create separate pages with tagging the name of the branch or release int he document name itself e.g.
- OFBiz 14.12 -- Ecommerce 14.12 -- Order Manager 14.12 ....... ....... ....... - OFBiz 16.12 -- Ecommerce 16.12 -- Order Manager 16.12 Best regards, Pranay Pandey HotWax Systems http://www.hotwaxsystems.com/ On Sun, Nov 13, 2016 at 3:31 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Hi Pranay, > > I like the idea, maybe you can use the same way I did it when I updated > the documentation for the Gradle move. > > I simply referenced with a link a previous version in history, eg: "Pre > Gradle version" notice at https://cwiki.apache.org/confl > uence/display/OFBIZ/Addressing+Custom+Requirements+In+OFBiz > > Jacques > > > > Le 09/11/2016 à 13:55, Pranay Pandey a écrit : > >> Thanks Taher for this note. Yes it is about document re-organisation and >> will help users to locate right set of document whenever needed. >> >> I am getting your point on priorities, but at the same time think that >> fine >> tuned user stories will older branch will help us building good set of QA >> artefacts for OFBiz upcoming release as well. >> >> I have also worked with one of my team member(Swapnil M Mane) to come up >> with a renewed OFBiz tutorial for beginners. Very soon we'll add it to >> OFBiz Confluence. Then we can discuss to upgrade it as needed for making >> it >> more easy to understand and useful. >> >> Best regards, >> >> Pranay Pandey >> HotWax Systems >> http://www.hotwaxsystems.com/ >> >> On Tue, Nov 8, 2016 at 4:53 PM, Taher Alkhateeb < >> slidingfilame...@gmail.com> >> wrote: >> >> Hi Pranay, >>> >>> It is a good idea of course to keep multiple versions of documentation >>> for >>> multiple releases. >>> >>> Talking in terms of priority, however, I think perhaps we need to spend >>> most of our energy into first organizing and cleaning up our >>> documentation. >>> We need an API section, a user manual, a developer manual, and a set of >>> tutorials. All of these need to be categorized and point to each other in >>> hyperlinks. Right now, the documentation is heavily scattered in >>> different >>> and confusing sections. There is no "one location" for getting a piece of >>> information. So for example, the business processes could be maybe part >>> of >>> the "User Manual" right? We don't have such a categorization at the >>> moment >>> which dilutes value. >>> >>> Also if you think about it, good organization of this information would >>> make it easier to create release-specific documentation because you're >>> building on the same organized skeleton. So in short I agree with your >>> approach but trying to convince you to perhaps try to focus your energy >>> on >>> organizing our documentation if you have the time for it. >>> >>> Thank you as always for your initiative. >>> >>> Cheers, >>> >>> Taher Alkhateeb >>> >>> On Tue, Nov 8, 2016 at 2:08 PM, Pranay Pandey < >>> pranay.pan...@hotwaxsystems.com> wrote: >>> >>> Hello Everyone, >>>> >>>> I am thinking to make a change in document hierarchy for Business >>>> Process >>>> and Use Case Library for Ecommerce ERP >>>> <https://cwiki.apache.org/confluence/x/1gm8Ag>. I think we can rename >>>> it >>>> for branch or release. >>>> E.g. we can prepare first set of documents for branch Release 14.12. So >>>> >>> the >>> >>>> document hierarchy will look like: >>>> >>>> - Business Process and Use Case Library for Ecommerce ERP >>>> -- Release 14.12 >>>> -- Release 16.12 >>>> -- and so on >>>> >>>> So the idea is to dedicatedly build documents for specific branch or >>>> releases. This way a set of the documents will be declared to be used >>>> >>> for a >>> >>>> specific release being used. As we start preparing for the new release, >>>> >>> we >>> >>>> can copy from old release and append the additions to it. We can then >>>> >>> also >>> >>>> add test cases(with a mark of success or failure for each for all the >>>> components) along with User Stories and Use Cases which will add more >>>> >>> value >>> >>>> to it. >>>> >>>> With its current name and structure it indicates, it's for trunk and >>>> >>> having >>> >>>> it managed on release basis will bring in more attention to it. >>>> >>>> Please let me know your thoughts on it. If no objections are seen I >>>> would >>>> like to make this change in a day or two. >>>> >>>> Best regards, >>>> >>>> Pranay Pandey >>>> HotWax Systems >>>> http://www.hotwaxsystems.com/ >>>> >>>> >
