+1
Agreed on all points.
I definitely would prefer an experimental flag to disable features until
they are ready for a release. This helps to avoid things like merge
conflicts, it gives all devs a better view of the codebase, and it also
makes it easier to test out new experimental features and provide
feedback without having to do a build from a different branch.
I'm looking forward to seeing the new features, even in an early stage!
On 5/10/22 9:33 AM, Mike Beckerle wrote:
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 <[email protected]> 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>
[email protected]<mailto:[email protected]>
[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
-----------------------------------------------------------------
