I have a few ideas here. I suggest work toward "next release" should happen on 'main'.
Only if needed (such as a security issue), AND there is no easy near term new release available on the 'main' branch then we create a maintenance branch for the prior official release. But I would do this lazily only if needed. For the main line of development, I would suggest just do it on 'main'. Creating 'dev' branches can be a pain (esp if someone refactors some code). If flags can be added to enable experimental features (that default to off) then I suggest using that technique and keeping the development of those features on 'main'. If this proves too clumsy then 'dev' branches are always possible. As for gathering requirements for next release, a roadmap wiki page laying out themes or high-level objectives for releases or sub-efforts makes sense. Then people can comment on it and it can be revised to match community interest over time. Then the issues/tickets associated with the repository can be targeted at releases described in the Wiki document when it makes sense to do so. The base library roadmap wiki page is this: https://cwiki.apache.org/confluence/display/DAFFODIL/Roadmap+for+Upcoming+Releases There's no official policy on when and how to modify tickets to reflect releases/plans/goals/desires. So far I think practice has been "just do it" and modify tickets as you see fit, and if it leads to discussion and further change here to converge community thinking, that's all just good. -mikeb On Mon, May 9, 2022 at 5:46 PM Shearer, Davin <shear...@ctc.com> wrote: > Hello daffodil developers, > > I have forked the repository and a small group of developers and I have > started working on some new features for a future version of the extension, > mostly (but not exclusively) centered around the target of the daffodil > debugger: the data. > > The data could be any kind of file, and could be very large, so having a > robust hex editing capability is important, so we’ve started assembling and > integrating one. Right now we’re working on integrating the basic editing > primitives (delete, insert, overwrite, undo/redo, cut & paste). Once we > have a solid hex editing capability, we’d like have the ability to set > breakpoints not only in the schema, but also in the data, and allow for > manipulating the data and watch it affect the parse. In other words, what > happens to the parse when I change the data in some way. > > We have also made some improvements to the DFDL syntax colorization and > Intellisense (these may even be appropriate for a v1.1 release as they are > improvements on what we already have, and not brand new features). > > We’re in early stages of development, but would like to contribute what > we’ve developed so far. I didn’t want to open a merge request against main > because I don’t want to hinder/disrupt any v1 fixes and updates. > > I suggest either (1) create a v1.x branch from the current main branch for > v1 fixes and updates and merge new features to main until we’re ready for > another feature release or (2) create a v.Next branch from the current main > where features and updates destined for the next major version are merged. > I don’t have a strong opinion either way, but do think we should have > different branches for supported major releases and next release > development. Any thoughts on this branching idea? > > Also are there any thoughts on how we should gather the features we want > for the next major release? > > Thanks, > Davin > > Davin Shearer > Senior Principal Engineer > Concurrent Technologies Corporation (CTC) > 8539 Corridor Drive > Savage, MD 20763 > Office: (301) 543-3905 > www.ctc.com<http://www.ctc.com> > davin.shea...@ctc.com<mailto:davin.shea...@ctc.com> > [signature_125693039] > Your comments and questions are important to us. Please submit your > feedback<http://www.ctc.com/Public/ContactUs/QualitySurvey.aspx>. > > > > ----------------------------------------------------------------- > This message and any files transmitted within are intended > solely for the addressee or its representative and may contain > company proprietary information. If you are not the intended > recipient, notify the sender immediately and delete this > message. Publication, reproduction, forwarding, or content > disclosure is prohibited without the consent of the original > sender and may be unlawful. > > Concurrent Technologies Corporation and its Affiliates. > www.ctc.com 1-800-282-4392 > ----------------------------------------------------------------- >
